It's not solely about compile times though. If you consider all the debugging time Rust saves you from, I'd guess Rust even with its slower compile time, comes out ahead in terms of productivity.
That is after all what this link is telling us. One of the main points made was "speed up development"
If it were solely about compile times that wouldn't be a major reason to use Rust here.
Only a sith deals in absolutes, it's not solely about _anything_.
I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories.
Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not
That's not possible at all with the bare-metal languages.
I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable.
Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
You're thinking of data races, but, (safe) Rust doesn't have data races. You can't write them.
In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice.
The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
Go compiles near instantly, having used Rust and Go for some time now, and shipped in both, Go is the clear winner if you value being able to iterate quickly.
Maybe? I found Go pretty stifling and ran into corners where I was faced with having to copy/paste a lot, write a code generator, or resort to ditching type safety. None of those options are very satisfying. I know generics are now there so maybe this has changed since I last used it. Good if so! 100kloc go program was fast to compile, but awful to modify.
It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
Same! I’ve written reasonably large programs in both. Go definitely has a lower learning curve and there’s absolutely value in that and it’s faster compile times. In a team with mixed experience and backgrounds making web or network services? Maybe go is the right way to go. Not everyone wants or is willing to climb the rust learning curve.
I do think the quick iteration tapers off though the larger the code base gets due to the points I mentioned.
Yeah if you punt the complexity to run time you can burn run time cycles instead of compile time cycles. Make your user pay to run your code instead of your developers. Go is more anti-end-user than Rust.
As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s.
There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions).
There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
> you're careful with your dependencies and optimizing for compile time, it can be quite good.
The same can be said about c++.
On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times.
> So overall I would say it's definitely a factor, but not necessarily a showstopper.
I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph).
Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow.
Frankly it depends, just like in C++, how the code is written.
Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.
I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust would absolutely ruin our compile times.