Ultimately it's the fact that compile time was not a first-class consideration during the design of Rust's important features. There's only so much you can do to mitigate the consequences.
Compilation times were a consideration, but they were a subservient consideration to the prime considerations of 1) being as memory-safe as GC'd languages, 2) exploring the limits of statically-guaranteed thread safety, and 3) being as fast and memory-efficient as C and C++. If Rust had been willing to compromise on those goals and instead had just, for example, used a virtual machine with pervasive garbage collection and been designed for dynamically-dispatched generics then you'd get a lot of compilation time reductions for free, but the world didn't need another Java, it needed a more secure systems language to stand up against C++ where every previous challenger had failed.
No, Rust is not at the paretto frontier for your mentioned 1, 2, 3 and also 4 compilation speed. It could have all of those things and also just have faster compilation. Rust devs have talked about how they have some regrets about not optimizing more for compilation, but instead another attribute got optimized in terms of paretto efficiency - the language's development time. Arguably I think that is the single worst trait you can optimize for in language development, because by saving a little time developing the language you cost humanity, let's say hundreds of millions of hours of development time downstream from you, with millions of users being less productive.
> It could have all of those things and also just have faster compilation.
Rust was originally a research language. It wasn't even clear that their primary three goals--"safe, concurrent, fast"--were simultaneously achievable to their desired degree. That it turned out to be possible was one of the most surprising and impactful results in the history of language design; even the early formulations of Rust assumed that both a garbage collector and a green thread runtime would be necessary, neither of which turned out to be true. That Rust could have faster compilation is both true and vacuous; there's always more optimizations to be eked out. The main question is whether or not significant performance wins could be gained by having made different, fundamentally-backwards-incompatible design decisions, and the answer is no, not really. Performance-related features like referentially-transparent procmacros can easily be made the default over an edition, and polymorphization can be implemented via an alloca-based virtual-dispatch ABI vis-a-vis Swift.
> Rust devs have talked about how they have some regrets about not optimizing more for compilation, but instead another attribute got optimized in terms of paretto efficiency - the language's development time.
No, the early Rust devs got this right. They were in fact highly incentivized to care about compiler performance, because rustc has been bootstrapped since 2011, making them the most serious users of the language in earnest (with the second-most serious users being the Servo devs one cubicle over). Rust spent years getting its basic design nailed down, then it did the hardest thing for any language: understanding the importance of shipping, resisting the urge to endlessly pursue perfection, and future-proofing what they could. Without shipping a useful language you can't get in the hands of users, and without getting in the hands of users you can't discover your most important flaws in practice. And because Rust shipped in 2015, it had ten years to hammer itself into shape to weather the agentic era; it could have easily still been on version 0.113 by now, puttering around in an ivory tower with no commitment to stability and no real users to give feedback.
While it has found success on mainstream, it basically proven Cyclone ideas were right, and now we have other languages adopting similar ideas into their type systems, which helps closing the gap with 3).
Since the 2000's we have been on the wrong path, many developers kept reaching for C and C++, not because they needed the actual features of a systems programming language, rather they didn't knew anything else that would ahead of time compile to native code, or even if they did the mindshare wasn't relevant for them.
Now thankfully we are circling back to how it should have been all along.
However all of this might be meaningless in the age of AI driven programming, where developers have no clue if the agent is driving automatic or stick, while delivering on the Markdown file plan.
Surac · · focus · HN ↗
What is the performance killer?
senderista · · focus · HN ↗
kibwen · · focus · HN ↗
applfanboysbgon · · focus · HN ↗
kibwen · · focus · HN ↗
Rust was originally a research language. It wasn't even clear that their primary three goals--"safe, concurrent, fast"--were simultaneously achievable to their desired degree. That it turned out to be possible was one of the most surprising and impactful results in the history of language design; even the early formulations of Rust assumed that both a garbage collector and a green thread runtime would be necessary, neither of which turned out to be true. That Rust could have faster compilation is both true and vacuous; there's always more optimizations to be eked out. The main question is whether or not significant performance wins could be gained by having made different, fundamentally-backwards-incompatible design decisions, and the answer is no, not really. Performance-related features like referentially-transparent procmacros can easily be made the default over an edition, and polymorphization can be implemented via an alloca-based virtual-dispatch ABI vis-a-vis Swift.
> Rust devs have talked about how they have some regrets about not optimizing more for compilation, but instead another attribute got optimized in terms of paretto efficiency - the language's development time.
No, the early Rust devs got this right. They were in fact highly incentivized to care about compiler performance, because rustc has been bootstrapped since 2011, making them the most serious users of the language in earnest (with the second-most serious users being the Servo devs one cubicle over). Rust spent years getting its basic design nailed down, then it did the hardest thing for any language: understanding the importance of shipping, resisting the urge to endlessly pursue perfection, and future-proofing what they could. Without shipping a useful language you can't get in the hands of users, and without getting in the hands of users you can't discover your most important flaws in practice. And because Rust shipped in 2015, it had ten years to hammer itself into shape to weather the agentic era; it could have easily still been on version 0.113 by now, puttering around in an ivory tower with no commitment to stability and no real users to give feedback.
pjmlp · · focus · HN ↗
Since the 2000's we have been on the wrong path, many developers kept reaching for C and C++, not because they needed the actual features of a systems programming language, rather they didn't knew anything else that would ahead of time compile to native code, or even if they did the mindshare wasn't relevant for them.
Now thankfully we are circling back to how it should have been all along.
However all of this might be meaningless in the age of AI driven programming, where developers have no clue if the agent is driving automatic or stick, while delivering on the Markdown file plan.