Go is known by the speed of it's compiler, doing extra work during the compilation would slow it down. I would not mind either to have a "release" flag that would take minutes and produce a more optimized binary.
As proven by D, OCaml, F#, Delphi, Ada, C++23 (with modules, VC++/clang 18), it is a matter of toolchain.
What we need is a Rust interpreter, or having something like Cranelift properly integrated, to only depend on LLVM when doing release builds on the CI/CD.
Having used Scala for some years with it's abysmal compile speed, I fear it has to do with complexity of the language and features, it was "implicit" in Scala, it might be the borrow checker in Rust (IANACG)
Note that I left out Scala, while I included other languages of similar complexity, exactly because improving compile times has never been a major focus in Scala land, versus features.
Example, development effort wasted on Scala 3 Python like syntax.
There are several performance reports that show that the major culprit is the pile of LLVM IR sent to the backend.
What we need is a Rust interpreter, or having something like Cranelift properly integrated, to only depend on LLVM when doing release builds on the CI/CD.
The largest single bit tends to be codegen, which is why cargo check is so much faster than cargo build.
Example, development effort wasted on Scala 3 Python like syntax.
There are several performance reports that show that the major culprit is the pile of LLVM IR sent to the backend.