Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

I would probably have gone with generating C here. You don't need all the safety of the Rust compiler, you're the one generating the code. As you point out, you can check all the constraints you want before you compile it.

Loss of automatic inlining of non-generics without LTO, to be a little pedantic.

Functions marked #[inline] can still be handled across crates.

LTO can inline across crates but, of course, at a substantial compile time cost.

How can you get around Rust's lack of a stable ABI?

And Rust's module design makes this significantly more complicated than in superficially-similar languages. That's why splitting it into modules brings drastic improvements - you are effectively giving the compiler clear boundaries across which it doesn't need to propagate as much information.

you are missing a lot of things

- Compilation is an inherently hard to parallelize thing, and not just hard to parallelize but there are a lot of trade offs. This trade offs aren't even rust specific (i.e. C,C++, etc. are affected as much) and can lead to less performant generated binaries. And much more memory pressure which could make the compilation in total slower. Luckily for most code this doesn't matter as long as you don't goo too parallel. But's it's the reason why max codegen units is 16 not #num_cpus (for release builds, 256 for debug builds).

- Codegen means producing machine code, i.e. we are speaking about of LLVM so the bug might not be rust specific and might affect other languages, too.

- This still should mean 16 threads at high load not 1, so they seem to have hit a perforamnce-bug, i.e. not how things normally work. It's very unclear if the bug is in rust of LLVM if it's the later C/C++ might be affected, too.

- While rust does strongly prefers you splitting you code into multiple crates, it still shouldn't be stuck at a singe threat, i.e. from everything we can tell we are hitting some performance bug.

- Algorithm most times dominate performance much more then if you language is slightly faster or slower this is clearly an algorithmic error i.e. failing to parallelize while it normally does parallelize and the issue might be in C/C++ code, so "rust is fast" has pretty much nothing to do with this.

- Through it still should be mentioned that for certain design reasons rust doesn't want you to make a single crate too large. In most normal situations you often end up splitting a crate for various reasons before it becomes too large, but if you have a very huge blog of auto generated code that is easy to miss. Funnily what can lead to compiler time issues if your crate is way to big also does "in general" lead to better performance which brings us back to a lot of decisions in compilers having trade offs.

> then what's the value of that language from a software engineering viewpoint?

You mean besides producing fast code in a way which is much better to maintain then C++ (or many other languages) but has many of the benefits C++ has over C when it comes to being able to reuse code and algorithm which practically makes it much easier to use better algorithms which often is a much higher performance gain then any normal language code optimizations. Something which has shown repeatedly in Praxis. Not even speaking about the fact that tends to have less bugs, makes it much easier to communicate interface constraints in a reliable maintainable way etc.

The argument of a single case of running into a compile time performance bug while already doing something which isn't exactly a normal use case and doesn't follow the common advice to split crates if they become large somehow implying that rust has no value for software engineers is just kind dump. I mean you also wouldn't go around saying cats have no value from a family POV in general because one specific case where a cat did repeatedly scratch a teenager twice.