FWIW i do not care that much about having LLVM's optimizations. As long as there are a few decent optimizations to do most of the stupid stuff i'm fine - i can do the rest myself whenever (and if) needed. It is only a very tiny part of the codebase that would need heavy optimizations anyway, yet having to pay (in terms of compilation time) for that for the entire codebase is an absurdity that we just seem to got used to.
I don't understand what your point is. I think you're trying to imply something like "rustc is fundamentally misdesigned and it would be easy to make huge performance improvements", but there really is not much low-hanging fruit left in rustc. The fact is that H-M type inference, borrow checking, and optimization take time. There is no magic bullet that other languages do to compile quickly that Rust does not, other than not having Rust's features or not doing optimization. There's even an entirely separate compiler implementation now, mrustc, which as far as I know is not significantly faster than rustc.
There was a time when rustc could be called a relatively slow compiler for what it does, but not anymore. It's actually a reasonably fast compiler now. I expect small wins to continue in the future, but the only remaining foreseeable large win is Cranelift.
I didn't say it is easy, just that there is still room for improvement.
So here go my couch coach ideas.
You already mentioned one possible improvement, I don't need to compile with all optimizations turned on on debug builds.
Secondly, combine JIT for development with AOT compilation for release deployment, e.g. Eiffel / .NET Native.
Thirdly, make use of a build cache across crates, including third party dependencies instead of building the whole world from scratch.
Combine that with an incremental compiler/linker, like Visual C++ does, where the team use Unreal, CryEngine, Windows, Office and other similar sized projects to measure build improvements.
Optimizations are not turned on for debug builds and never have been. The issue is that LLVM is still pretty heavyweight even when not optimizing. An entirely separate backend is needed.
As Steve mentioned, there is a global build cache already.
We have an incremental compiler. It's not as incremental as it could be, however.
We already have an extensive system, crater, that can measure build time improvements.
And incremental compilation is more than virtually all the listed compilers can do.
I think the issue is more that not many people are using those languages in anger (except for Delphi I suppose, but Object Pascal is a comparatively simple language with no H-M inference that also does very little optimization). People don't hit the limitations.
