让 Rust 编译器变慢是一个价值十亿美元的错误吗？
2 分•作者: breatheoften•6 个月前
只是想知道，其他人是否也对目前领先的现代系统编程语言没有将快速编译作为其基本设计目标之一而感到越来越不满。<p>对我来说——这似乎是未来“十亿美元”错误回顾性文章的明显候选者。<p>为什么“支持快速编译”不是任何希望实现广泛使用的现代语言的必要先决条件？<p>特别是对于 Rust 而言——似乎很多编译速度慢的行为并非该语言最重要的任何方面所必需的……<p>有没有人尝试过以一种故意破坏兼容性的方式来分叉 Rust 生态系统，以便为该语言和生态系统规划一条最简单的快速、可扩展的编译策略？<p>我有一种感觉，这样的努力——移除了一些 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 ...