如何在 2026 年 9 月加快 Rust 编译器

原文 ↗ Hacker News 讨论 ↗

优化 Rust 编译器仍是重点，近期围绕更好的算法、增量与并行编译以及宏缓存的工作，在大型基准套件上带来了约 4–5% 的可测提速。评论者讨论了为何 Rust 构建仍明显慢于 C、Go 或 Zig——通常归因于泛型与单态化、沉重的 LLVM 优化、宏和静态分析——同时分享了拆分 crate、使用替代后端和链接器、以及编译器缓存等实用缓解策略。许多人认为，更快的编译对人类生产力和 AI 智能体工作流都至关重要，并主张性能与安全保证虽然重要，但必须与迭代速度取得平衡。

整体改进与关注点

  • 评论者认为，最近在数百个基准测试上实现约 4.5% 的平均墙钟时间下降非常可观。
  • 许多人指出，真正的大幅提升来自算法改进（例如更好的控制流遍历，大幅减少某些分析调用），而不是对热点循环做微优化。
  • Polonius/trait solving 的新工作，以及“只在需要时才做昂贵分析”，被视为推动 Rust 走向更有针对性、按需驱动的编译。

为什么 rustc 很慢（以及它和别的语言相比如何）

  • 没有单一原因：提到的因素包括泛型和单态化、偏重迭代器的惯用写法、复杂的 trait 求解和类型推断、借用检查、沉重的 LLVM 优化，以及大量调试信息。
  • 多篇帖子强调，惯用 Rust 天然会使用很多泛型（例如 Option、Result、迭代器链），这会给 LLVM 带来大量 IR，也会增加链接器的工作量。
  • 有人认为 trait 求解通常不是主要瓶颈；IR 体量本身加上 LLVM 和链接才是主因。
  • 与 C 相比，Rust 和 C++ 被看作在速度上大致相近，而且都远慢于 C；Go 和 Zig 则被指出是刻意用特性和优化换取更快的编译。
  • 也有人认为，Rust 本可以在安全/性能与编译时间这两个维度上设计得更接近帕累托前沿，但在语言设计阶段编译速度并不是优先项。

工具、后端与链接

  • 链接经常是符号很多的项目中的瓶颈，即使在调试构建中也是如此；更新的链接器（例如 wild）能改善情况，但需要显式配置。
  • Cranelift 因代码生成极快而受到称赞，但也因调试器支持差、缺少 intrinsics 而受到批评；有人怀疑它会成为稳定后端。
  • 宏和 proc-macro 展开被认为是主要开销。实验性的 proc-macro 缓存（-Zcache-proc-macros）在宏很多的 crate 上展示了两位数百分比的提速，但是否稳定以及默认启用的语义问题仍未解决。

项目结构、缓存与磁盘占用

  • 将大型代码库拆分成多个 crate 可提升并行度并减少每次编辑后的重编译，但不能解决链接时间。
  • 强烈建议使用全局和共享缓存（例如 sccache，以及更新的工具如 kache）；没有这些时，许多并行沙箱会把相同依赖重复编译。
  • 大型 Rust 项目会积累巨大的 target 目录和增量构件（数百 GB），不得不定期手动清理；如何安全回收缓存空间被描述为尚未解决或极其困难的问题。
  • 有人建议使用包装器或全局构建锁来避免 CPU 超额订阅，否则会让构建明显变慢。

并行与推测式编译思路

  • 当前正在推进并行前端和 TPDE（type-driven partial compilation），它们可能带来更大的提速。
  • 一位评论者描述了一个实验性分支：更早输出元数据，让依赖 crate 能更早开始，在深层嵌套项目上带来显著的墙钟时间下降；如何处理错误报告和推测性“浪费”工作仍是开放挑战。

Rust、智能体与迭代速度

  • 几篇帖子把 Rust 视为“agentic AI”产物的强匹配：原生、低缺陷、对人类可读，而且适合严肃的桌面应用。
  • 也有人因为编译慢、依赖重、磁盘占用大而放弃 Rust，转向 Go 或其他语言，因为这些因素让多智能体工作流很痛苦。
  • 有人认为，对于大型组织和现实项目，Rust 和 Go 团队的生产力大致相当，因此只关注编译时间是有误导性的；也有人反驳说，更快的编译仍然能显著提升生产力，尤其是在 AI 驱动的迭代场景中。

语言设计取舍与替代方案

  • Go 和 Zig 被当作编译器性能影响语言设计的例子；Rust 被描述为“既想要蛋糕又想吃掉它”，拥有许多特性和检查。
  • 有人提到其他生态（D、OCaml、Haskell、Ada、Delphi、C++）中存在快速编译器、解释器、REPL 或热重载工具，并认为 Rust 的主要缺口是生态/工具，而不是语言本身的固有成本。
  • orphan rule 被称为一个主要痛点，但也是编译时一致性的胜利；有人对在 workspace 中放宽它感兴趣，尽管这可能让编译和性能变得更复杂。
  • 少数人认为 Nim 或其他“中间路线”语言，比 Rust 的复杂性与 Go/Zig 的简洁性之间更平衡。

资金、LLM 政策与影响力

  • 社区普遍欢迎企业向 Rust 基础设施捐款，因为这有助于持续推进性能工作；有人认为，如果能展示开发者等待时间减少 5%，这种投资就足以成立。
  • 也有人担心，大额捐助者即使没有正式控制权，也会通过优先资助符合自身需求的工作而微妙地影响优先级。
  • Rust 项目的 LLM 政策禁止直接提交 LLM 生成的代码，但允许将 LLM 用于分析和辅助；至少有一位编译器工程师明确表示自己就是这样使用 LLM 的。
  • 关于 LLM 写的代码，或者 AI 公司提供的大量免费 token 是否应在加速编译器开发中扮演更大角色，存在争论。

对 Rust 在 AI 时代价值的怀疑

  • 一些参与者质疑，在 AI 时代 Rust 为什么还吸引人：他们认为原始运行时性能的重要性不如以往，而 Rust 的冗长、复杂类型和缓慢编译会浪费人类和 AI 资源。
  • 这些怀疑者把静态类型（以及类比之下 Rust 的安全保证）描述为 LLM 不需要的“辅助轮”，类似于他们认为过度使用 TypeScript 会导致代码库过度设计、充满仪式感。
  • 另一些人强烈反对，强调 Rust 的保证和运行时效率正是构建健壮、低缺陷系统所需要的，即使这意味着在编译时付出更多成本。