>Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
Refactor your build.
>It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end?
If you can come up with something better, write a macro for it.
>Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.
Learn the language a bit better, use code coverage tools, and write better tests.
>When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs.
True for C++, too, if you don't implement things properly.
Although naively factored builds can be slow on rust, I firmly believe that most folks complaining about this problem have not taken the time to learn how to do this and their builds could be perhaps 10x faster. Bringing this up an important counter-point that all too frequently is ignored or met with hostility, as this replier has done.
I do not understand how you justify your claims. Should I link any number of instances where Rust team members admit to compile times being a major issue, one which prompts significant effort to improve? Perhaps you are right about 10x speedups, but then that clearly isn't enough, reading the room.
I also do not understand how you see hostility in my comment. For one thing, I did not downvote you. Rather, your original comment is dismissive, even if the article it replies to is dubious. For another, it would also be trivial to see that I am both highly supportive and informed about Rust. Your comments simply do not help, certainly not with the common perception of Rust fans as zealots.
Don’t know what to tell you. Just trying to keep things real in response to a highly ungrounded post. The issues with compilation times are as severe an issue because of the reason I mentioned — folks don’t like to think about how they factor their build. So some members of the core team are sympathetic to that — and for good reason.
But the virtues of shifting context to the build and refactoring it is rarely discussed and would alleviate many individuals problems. I see it rarely mentioned, just “rust is slow to compile” so I really do feel it should be discussed more; even if I could have perhaps mentioned it in a way you (and others?) would have experienced as less dismissive.
I can't speak for everyone, or even the majority, but I know that oftentimes large projects focus on build times, undergoing refactorings as you describe, and their compile times are still high. To make up some numbers, maybe the fraction of projects that have unacceptable compile times could be reduced from 80% to 40% (at what effort?), but that 40% remainder probably includes many large, popular crates.
Refactor your build.
>It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end?
If you can come up with something better, write a macro for it.
>Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.
Learn the language a bit better, use code coverage tools, and write better tests.
>When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs.
True for C++, too, if you don't implement things properly.