Rust 1.23 Lowers Rustc Memory Usage

[discordian]

To be fair it is probably hard for C and C++ guys to get into Rust because Rust requires you to write good code which is something C/C++ devs are unfamiliar with as it is simply not possible to write good code in C/C++. You can't just assume that you can convert a program to Rust by just changing the syntax, you need to change the whole structure of the program as Rust doesn't tolerate the bad structures that C/C++ do. There is a reason all C languages are banned by NATO countries for defence software and nobody in the civilian world uses any C lang for safety critical systems.

Lol, either you are a very successful troll or you are completely out of touch with reality. There are norms and standards for safety and security (most commonly the SIL Levels), I have yet to find anything that isn't C,C++ or Assembly with the necessary restrictions ala MISRA.

https://en.wikipedia.org/wiki/MISRA_C

https://en.wikipedia.org/wiki/IEC_61508

Yoe can write safe C/C++, you just need to be competent the proof is that any security relevant software IS written in C/C++ despite their drawbacks. Funny enough as soon as you use more complex structures the simple ownership rules of Rust will show their limitations and you need various workarounds, Rust being a good solution (outside small projects whete some simple guidelines for C++ will suffice) is just wishful thinking for now.

[tuurtyret]

You can write good code in any language. I like what Qt makes with C++ possible, even before C++ 11. It feels a little bit like Java.

No you can't. I could never step foot into a self-driving car that software is not written in Rust.

[mmstick]

That was my experience too. Dropped it after a couple of days trying to write some nontrivial piece of code.

I've been writing software with Rust for two and a half years. The only time I had difficulty with the borrow checker was within the first week or two of learning Rust. If you are fighting the borrow checker, it is because you are writing very dangerous, memory-unsafe code. Therefore, you can't blame the language for your own unsafe coding habits. The borrow checker is not fighting with you -- it is teaching you how to write safe code, and it will not compile your program until you write it safely. To use a metaphor, the Rust borrow checker is like a Chinese finger trap -- the more you struggle, the stronger the trap becomes. Ease up and follow the rules, and everything falls into place.

The rules are very clear and simple, so all you have to do is use the borrow checker to your advantage, rather than trying to oppose it.

- Only one unique mutable reference at any given time
- Mutable references can invoke immutable and mutable methods alike, or be transformed into immutable references
- As many shared immutable references as you want, yet you can't create a mutable reference while an immutable reference exists
- Immutable references can invoke only immutable methods
- The owner of the variable can invoke methods which move the variable, as well as immutable and mutable methods.

There is no challenge that is difficult to implement whilst adhering to the rules above. You just have to follow them. There are many great strategies that you can employ to safely accomplish every type of problem.

[mmstick]

Funny enough as soon as you use more complex structures the simple ownership rules of Rust will show their limitations and you need various workarounds, Rust being a good solution (outside small projects whete some simple guidelines for C++ will suffice) is just wishful thinking for now.

You say that, but it's simply not true. This sentence flies in the face of many complex libraries and applications that have been successfully developed in Rust in record times. Many feats have been achieved that would be impossible to pull off with C/C++ by human hands, or would have required an insane amount of time to develop and ship in production. C and C++ have both been proven to be inadequate for build complex applications and libraries. It cannot be trusted, and the APIs produced by these languages are too cumbersome to maintain.

[andrebrait]

I've been writing software with Rust for two and a half years. The only time I had difficulty with the borrow checker was within the first week or two of learning Rust. If you are fighting the borrow checker, it is because you are writing very dangerous, memory-unsafe code. Therefore, you can't blame the language for your own unsafe coding habits. The borrow checker is not fighting with you -- it is teaching you how to write safe code, and it will not compile your program until you write it safely. To use a metaphor, the Rust borrow checker is like a Chinese finger trap -- the more you struggle, the stronger the trap becomes. Ease up and follow the rules, and everything falls into place.

The rules are very clear and simple, so all you have to do is use the borrow checker to your advantage, rather than trying to oppose it.

- Only one unique mutable reference at any given time
- Mutable references can invoke immutable and mutable methods alike, or be transformed into immutable references
- As many shared immutable references as you want, yet you can't create a mutable reference while an immutable reference exists
- Immutable references can invoke only immutable methods
- The owner of the variable can invoke methods which move the variable, as well as immutable and mutable methods.

There is no challenge that is difficult to implement whilst adhering to the rules above. You just have to follow them. There are many great strategies that you can employ to safely accomplish every type of problem.

Have you read the article posted sooner here?
Do you propose a solution for that case?

I'm genuinely curious. I like Rust but I couldn't propose a solution for that case myself.

[mmstick]

Have you read the article posted sooner here?
Do you propose a solution for that case?

I'm genuinely curious. I like Rust but I couldn't propose a solution for that case myself.

I'm not sure what you are talking about.

[andrebrait]

I'm not sure what you are talking about.

This: https://hackernoon.com/why-im-droppi...t-fd1c32986c88

[mmstick]

This: https://hackernoon.com/why-im-droppi...t-fd1c32986c88

There are many fundamental issues with that article (as was also pointed out way back in 2016 when this article was picked apart in the Rust subreddit).

The first of which is that you can access fields when implementing a trait. In the provided example, the author is not implementing a trait for a type, but attempting to create a generic trait implementation, which therefore doesn't have access to any fields. Implementing the trait on a type, on the other hand, allows for accessing fields, which you could use the getter/setter approach to implement generic methods with. And as a last side note to this issue, you may create traits that have associated types & constants now, which these trait implementations can take advantage of. HKTs aren't implemented yet though.

Yet the bigger issue is that the approach that the author is attempting to take for this problem -- class-based OOP, aka cyclic / graph-based data structures -- is exactly the kind of thing that Rust is actively discouraging, as this type of software architecture is a root cause for much memory / thread unsafety, and cannot be proven to be safe at compile time. The generic Rc/RefCell types may be used to create this kind of software safely, but the side effect is that you can't pass the wrapped values across thread boundaries, as a result of these kind of data structures being unable to be safely shared across threads. If one thread modifies an object, then that object's pointer could be rendered invalid to all objects which reference it, so other threads may be working off outdated / corrupt copies.

So the best approach would be to investigate superior software architectures. Among these, are entity-component system (ECS) architectures, which can and do safely scale across threads. It is an approach which became popular in the AAA game industry to solve this very problem regarding scaling complex systems across threads safely, and has been gaining popularity in the UI field as well, as it's a good alternative to this exact OOP problem. There does exist some generic ECS crates which you can use as a guide to implement your own libraries around ECS, such as specs, but a great example for using ECS to create a GUI library would be the relm abstraction for GTK, which is of course inspired by how Elm solves this problem.

But basically, if the author truly wants to create APIs like that, then the only languages that they should be allowed to use are the garbage collected languages that they are familiar with. This is just not a problem that can be solved safely without a garbage collector. It's therefore of no fault of the language that this is unsafe to attempt, but upon the developer to learn better software techniques so that they don't write APIs like this, or to quietly accept that they will have to work with raw pointers in the same fashion as they would do in C or C++.

[andrebrait]

There are many fundamental issues with that article (as was also pointed out way back in 2016 when this article was picked apart in the Rust subreddit).

The first of which is that you can access fields when implementing a trait. In the provided example, the author is not implementing a trait for a type, but attempting to create a generic trait implementation, which therefore doesn't have access to any fields. Implementing the trait on a type, on the other hand, allows for accessing fields, which you could use the getter/setter approach to implement generic methods with. And as a last side note to this issue, you may create traits that have associated types & constants now, which these trait implementations can take advantage of. HKTs aren't implemented yet though.

Yet the bigger issue is that the approach that the author is attempting to take for this problem -- class-based OOP, aka cyclic / graph-based data structures -- is exactly the kind of thing that Rust is actively discouraging, as this type of software architecture is a root cause for much memory / thread unsafety, and cannot be proven to be safe at compile time. The generic Rc/RefCell types may be used to create this kind of software safely, but the side effect is that you can't pass the wrapped values across thread boundaries, as a result of these kind of data structures being unable to be safely shared across threads. If one thread modifies an object, then that object's pointer could be rendered invalid to all objects which reference it, so other threads may be working off outdated / corrupt copies.

So the best approach would be to investigate superior software architectures. Among these, are entity-component system (ECS) architectures, which can and do safely scale across threads. It is an approach which became popular in the AAA game industry to solve this very problem regarding scaling complex systems across threads safely, and has been gaining popularity in the UI field as well, as it's a good alternative to this exact OOP problem. There does exist some generic ECS crates which you can use as a guide to implement your own libraries around ECS, such as specs, but a great example for using ECS to create a GUI library would be the relm abstraction for GTK, which is of course inspired by how Elm solves this problem.

But basically, if the author truly wants to create APIs like that, then the only languages that they should be allowed to use are the garbage collected languages that they are familiar with. This is just not a problem that can be solved safely without a garbage collector. It's therefore of no fault of the language that this is unsafe to attempt, but upon the developer to learn better software techniques so that they don't write APIs like this, or to quietly accept that they will have to work with raw pointers in the same fashion as they would do in C or C++.

I'm professionally a Java EE developer. The kind of thing he wanted to do with the trait (having access to a class' field) is pretty much what I'd do with an interface (in Java 8) or an abstract class for which I don't want to have the field in for whatever reason. I see no problem with it. Abstract getters/setters are pretty common.

Structures such as the one he wants to implement are also very common in the Java world. Now I know why. The GC simplifies things a lot, indeed.

I like lower level stuff too. I find Rust very cool, in the way the syntax was able to provide the compiler with all that information and all. Really cool stuff.

And thanks for giving your opinion on this. I'll be looking into ECS because I feel it may help out a bit here and there even in the GC'd land.

[polarathene]

I just dropped Rust after a 2 months trial for I realized it's too unproductive because of having to constantly fight the borrow checker, structure the code to the borrow checker's needs instead of yours and bad solutions to circular references, among other things.

That was my experience too. Dropped it after a couple of days trying to write some nontrivial piece of code.

Rust will certainly get better but these core issues can't be fixed because they and Rust's ownership are mutually exclusive, because they stem from Rust's core ownership rule of not having aliases to mutable references, e.g. you can't eat your cake and have it too.

Just so ya'll know, that's a well known pain point and the Rust language devs have been working on resolving it with a feature known as NLL(Non-lexical lifetimes). It's expected to be out in a release this year(around mid year I believe?). Few other big features being polished off that will help quite a bit too