Comment by pcwalton
1 year ago
Rust always cared about compile times. Much of the motivation to switch from rustboot to rustc was compile times.
(Source: I wrote much of the Rust compiler.)
1 year ago
Rust always cared about compile times. Much of the motivation to switch from rustboot to rustc was compile times.
(Source: I wrote much of the Rust compiler.)
The Rust ecosystem has long downplayed the importance of compile times.
Many foundational crates, serde for example, contribute much more to compile times than they need to.
I spent a long time reinventing many foundational rust crates for my game engine, and I proved its possible to attain similar features in a fraction of the compile time, but it’s a losing battle to forgo most of the ecosystem.
Thank you for your work! Rust is still a great language.
I think a significant portion of our pain with rust compile times is self inflicted due to the natural growth of our crate organization and stages.
I still think the rewrite in zig is the right choice for us for various reasons, but I think at least a chunk of our compile times issues are self inflicted (though this happens to any software project that grows organically and is 300k LOC)
But were any _language_ decisions discarded due to compile time concerns? I don't think anyone would claim the folks working on the rust compiler don't care.
On that note, thank you for your part! I sure enjoy your work! :)
Since at least 2018, there's been a planned upgrade to the borrow checker to permit certain patterns that it currently rejects [0]. Also since 2018, there's been an implementation of the new version (called Polonius) that can be enabled with an unstable compiler flag [1].
But now it's 2025, and the new version still hasn't been enabled on stable Rust, since the Polonius implementation is seen as far too slow for larger programs. (I'm not exactly sure how horrible it really is, I haven't looked at the numbers.) A big goal of the types team since last year has been to reimplement a faster version within rustc [2].
I'd count this as a language feature (albeit a relatively minor one) that's been greatly deferred in favor of shorter compile times.
[0] https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-u...
[1] https://github.com/rust-lang/rust/pull/51133
[2] https://rust-lang.github.io/rust-project-goals/2024h2/Poloni...
That’s useful information and we are all glad that performance regressions aren’t allowed now and there is work to make things faster. But that seems to be implementations of existing language design decisions rather than making language design decisions for the sake of compile times.
Yet, the whole crate model giving up on ABI stability as a goal hurts a lot, both for performance and for sanity.
Why aren't people designing modern languages to make it easier to keep a stable ABI, rather than giving up entirely?
ABI stability is one of those things that seems obvious ("sane"), until you try to implement ABI-stable unboxed generics and discover that the amount of complexity you incur, as well as the performance tax, is absurd. The code bloat with the resulting "intensional type analysis" actually makes the compile time worse (and the runtime far worse) than just specializing generics in many cases.
The Swift folks seem to manage just fine.
2 replies →
In this case (i.e. Rust specifically) what do unboxed generics mean. Without actually knowing Rust I don’t think I can analogize to either type theory or another language. I assume if I can figure out what they are I infer why they are difficult to compile.
1 reply →