让 Rust 编译器变慢是一个价值十亿美元的错误吗？
我在想，其他人是否也对当前主流的现代系统编程语言没有将快速编译作为其基本设计目标之一感到越来越不满。
对我来说，这似乎是未来一篇“十亿美元”错误回顾文章的明显候选主题。
为什么“支持快速编译”不是任何希望实现广泛使用的现代语言的必要前提条件？
尤其是对于 Rust 来说，许多慢编译的行为似乎并不是语言中最重要的方面所固有的……
有没有人尝试过在 Rust 生态系统中进行分叉，以故意破坏兼容性，从而为语言和生态系统绘制出一条通往快速、可扩展编译策略的最简单路径？
我感觉这样的努力——去掉一些不必要特性并简化包系统以加快编译速度的 Rust，实际上会迅速发展并能够相对快速地取代当前的生态系统……
查看原文
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.<p>To me -- this seems like an obvious candidate for a future 'billion dollar' mistake retrospective essay.<p>How and why is it that 'support fast compilation' isn't a necessary pre-condition for any modern language hoping to achieve serious usage?<p>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 ...<p>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?<p>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 ...