[aw1621107]

> It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.

I think one interesting thing that could be explored more is what aspects of Rust "inherently" result in slow compilation (i.e., if you changed said aspects to improve compilation speeds then you end up with a "different" language, assuming some hand-waviness with respect to equivalence here) and what aspects are practically and/or theoretically improvable.

For example, rustc's reliance on LLVM for optimization is a well-known source of sluggishness, but I wouldn't classify that as "inherent" since Rust could use a different backend that works faster (e.g., Cranelift) and/or be more efficient about the IR it emits. Something like monomorphization, on the other hand, is a more in a grey area since it's (as far as I know) essential for Rust to meet its performance goals, but IIRC it's not out of the question for the compiler to implement generics using a different strategy instead, which might be viable as an opt-in tradeoff.

[estebank]

There are at least three separate things that rustc and cargo could do to significantly improve compilation speed, but they are complex engineering efforts that require time and engineers being paid to work on full-time. They are: doing what zig does to compile only items that arr reachable, which requires making rustc reentrant to stop after name resolution and cargo more complex to pass used paths through subsequently, leveraging an incremental linker and have rustc only codegen the binary patch instead of the whole binary and have the linker calculate the patch, and caching proc-macros and treat them as idempotent (likely as opt-in). There are of course others, like pre-compiled distribution, better intra-rustc parallelism or feature cfg handling, but those have more open questions and require additional design work before I could claim they're attainable.

[aw1621107]

Oh, I hadn't heard that you guys are looking at Zig-style "targeted" compilation (for lack of a better phrase). That sounds like it entails quite a bit of infrastructure work. Is there a GitHub issue I can follow to keep an eye on progress?

Out of curiosity, have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?

[estebank]

You can see epage's replies to my copy of this comment for an idea of the open questions: https://hachyderm.io/@ekuber/115605792856416650

You can look at what is currently effectively staffed at https://rust-lang.github.io/rust-project-goals/#flexible-fas...

We discussed a lot of these last May in person. Haven't kept track of who's doing what on these fronts.

> have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?

Yes, but I haven't been part of all of them and can't ellaborate much here. Opening a thread in internals.rust-lang.org with that question might get some good info sooner that I could.

[aw1621107]

> You can see epage's replies to my copy of this comment for an idea of the open questions: https://hachyderm.io/@ekuber/115605792856416650

Those are some interesting discussions there! Decent number of things I hadn't considered.

> Opening a thread in internals.rust-lang.org with that question might get some good info sooner that I could.

I'll have to see about setting signed up, then (or finding my old credentials; don't remember if I ever had any).