Stories like this make me think something is wrong with your setup. Do you have Windows Defender or similar enabled on the build directory?
Doesn't mean one is better than the other, but to find it odd someone had an experience with slow Rust compiliations and then blame it on their setup is a bit odd.
Most of the Rust ecosystem makes unnecessarily heavy use of compile-time traits and monomorphized generics (aka Go generics or C++ templates). The language syntax encourages it as well. The thing is compile times will NEVER drop to level of Go unless the entire set of players (language, standard library, almost all library developers) actually prioritize dynamic dispatching instead of static dispatching / monomorphization. That's the tradeoff for the performance and RAM usage you gain. Template-heavy C++ also suffers from the same issues for the same reason.
Golang is fast to compile because its interface definitions are runtime/dynamically dispatched (aka `&dyn Trait` in Rust or virtual classes in C++) and it had no generics for a long time forcing types like slices, map and vectors to be magic types.
If you need fast compile times, you need to split your program into multiple binaries or write your own backend ecosystem that almost only uses dynamic dispatching. If your full Cargo dependency tree pulls 50+ crates, you'll not get fast compile times. You need to avoid derive-macros like plague. You need to use non-Cargo build systems or `build.rs` to generate Rust code instead of derive-macros.
Unlike Golang Rust also targets extremely memory constrained devices where monomorphization enables memory savings, extra optimizations and fewer CPU cycles / instructions (e.g. microcontrollers, UEFI/BIOS implementation). It is a system programming language first. With system programming languages you are responsible for these choices as the developer. Rust just happens to have a vivid scene of backend libraries since the language's safety enabled many non-system developers to write correct and performant programs quickly.
The typical end result sits somewhere between monomorphization and type erasure in terms of generated code and runtime indirection.
> The axiom is “monomorphic data, polymorphic code”. In other words, unlike languages like Haskell and OCaml that generally rely on uniform representations (boxing) to enable polymorphic code generation, data layouts will stay the same under polymorphization, and only function ABIs will change. [...] Go’s gcshape is somewhat analogous to our concept of data layouts.
It looks like TinyGo also had to make some compromises to reduce the memory footprint and increase optimizations: https://tinygo.org/docs/concepts/compiler-internals/differen...
> A whole program is compiled in a single step, without intermediate linking. This makes incremental development much slower for large programs but enables far more optimization opportunities. We are actively working on build caching so that at least part of the work does not need to be redone on every compilation.
But 15 minutes? Even rustc doesn't take that long (on a powerful computer), and that's a very large program that is compiled at least twice (bootstrapping)! That's just poor engineering, not knowing how to write fast-to-compile Rust code.
I just did a release build of Codex CLI with "lto = false" for codex CLI binary and code mode host only, and it took 75 minutes, of it 1063 seconds for the final rustc of codex bin. Windows Defender off. That's on a 4-core 2021-era Intel laptop with 32GB RAM and a half-TB SSD. And I can't let the build run at default concurrency, because rustc OOMs the machine, so this is with cargo jobs = 4. Regardless, the final rustc call is independent of that and that was 1063s with lto=false. Previous build was 90 minutes with default thinlto for the same CLI build.
How can Codex write fast-to-compile Rust code, do tell?? Do tell!
> How can Codex write fast-to-compile Rust code, do tell?? Do tell!
Like a human can, I suppose? Avoid extreme usage of generics. Avoid dependencies if not needed. Make sure you synchronize dependency versions to avoid duplicate code. Etc..
Alone that fact makes devs that have to deal with what they can afford, to pick other ecosystems that can be usable on their potatoes.
That isn't "Rust compiles are fast", it's another example of "Rust requires you architect your code a specific way".
That said, I would love for Idris to continue to develop. I'm a big believer in dependently typed languages and would actually improve correctness, assuming there are reasonable ways to avoid the other trappings of the language.
I would not include Ada, if you're benchmarking against Rust. Mostly because Ada either outperforms it (because it can reduce sizes in the optimiser), or it is equal to it.
And neither the original example is "Rust compiles extremely slowly" (it does compile slowly), it's another example of "vibecoded software is of poor quality".
One proposal I came across actually suggested breaking up a perfectly fine monolith into a dozen microservices to reduce compile times (at the cost of cumulative CI costs going up).
When the alternative is massively rearchitecting your systems, Zig and Go begin to look really nice by comparison.
I have no idea how this could possibly be this bad given that I worked full time with Rust from 2015 to 2023 on a $600 Clevo laptop from 2012 and was used to incremental builds in the low double digit seconds for projects ranging between 100k and 600k loc. (From scratch release builds where excruciatingly slow, but these only happened once every rust updates).