Is making the rust compiler slow a billion dollar mistake?
4 points by breatheoften 7 hours ago
Just wondering if other folks feel growing dissatisfaction with the fact that the current leading modern system programming language does not include fast compilation as one of its fundamental design goals.
To me -- this seems like an obvious candidate for a future 'billion dollar' mistake retrospective essay.
How and why is it that 'support fast compilation' isn't a necessary pre-condition for any modern language hoping to achieve serious usage?
With rust in particular -- it seems like a whole lot of the slow compilation behaviors are not fundamental to any of the most important aspects of the language ...
Is there anyone out there who has tried to fork the rust ecosystem in a way which deliberately breaks compatibility in order to chart the simplest path to a fast, scaleable compilation strategy for the language and ecosystem?
I have a feeling that such an effort -- rust with some misfeatures removed, and with the package system simplified in order to speed up compilation would actually take off and be able to replace the current ecosystem relatively quickly ...
I believe the Rust compiler does whole program analysis or, at least, something very similar in spirit. Hence, unless you completely change how the language works it can't be as fast as a simpler compiler. You can work around it by having a daemon that incrementally compiles only changed parts, but then you need to have that daemon running and it's never as smooth as one command that compiles quickly. In other words, yes, I think you are right. Slow compile times reduce adoption.