This won't necessarily always be so, there's e.g. a new compiler backend called cranelift in the works, that makes compilations 30%ish faster, and in return the code isn't as optimized - which is good for a faster inner cycle.
https://pingcap.com/blog/rust-compilation-model-calamity#rus...
fast execution, safe execution, fast compilation — choose 2.
This is a false(ish) dilema.
The problem of Rust is that is made with a C++ mindset. Is VERY hard to make compiler fast if it follow what C/C++ do (Go is the only evidence against!).
Is a death by thousands cut. The syntax is the FIRST and big one. How you chose it will impact all the pipeline. Then the rest...
But the things that make Rust safe are not that much slower. Macros, Generics, all that syntax, all that lang complexity (ie: Not just the semantics but the way is surfaced) have a bigger impact.
Only once that was worked around did they article really start having to pay attention to the code generation and linking stages, and the issues there seem to mostly be about lack of parallelism caused by the "crates" model combined with link time optimizations and incremental compiles being off by default. You don't need to make a fundamentally faster code generator that makes worse output to deal with this: the performance losses you get from parallel, incremental, and separate compilation techniques are so minimal that only the most serious C++ projects go out of their way to combine translation units and activate LTO.