2026 对 Rust 编译器（以及我）来说是令人兴奋的一年

原文 ↗ Hacker News 讨论 ↗

Rust 编译器在 2026 年的演进路线既带来兴奋也引发担忧：新的 trait 求解器、specialization 的推进、polymorphization，以及更好的调试信息默认值等计划，承诺减少技术债、二进制膨胀和 `target` 目录大小。许多开发者赞赏 Rust 的安全性和性能，但也指出长编译时间、庞大构建产物和硬件需求带来的现实痛点，尤其是在大型项目和 CI 中，与 Go 或 Python 相比更为明显。也有人质疑 Rust 是否还能继续作为未来的语言，或者一种兼具 Rust 式安全性与 Go/Zig 式简洁和速度的新生态最终会取而代之，尤其是在 AI 辅助工具改变代码编写方式的情况下。

标题处理与 HN 的怪癖

  • 多个投稿的标题被自动更改；HN 的自动“修正”有时会把合理的标题或笑话弄乱。
  • 由于编辑限制，正确标题只能稍后再修正。

编译时间与 target 目录膨胀

  • 多条评论提到 target/ 目录非常大（从几十 GB 到约 190 GB 不等），而且对笔记本电脑/较小磁盘造成限制。
  • Rust 的大量调试信息和单态化，以及庞大的依赖树和由 feature 驱动的 crate 重复被认为是膨胀的主要原因。
  • 建议的缓解措施包括：debuginfo = "line-tables-only"（很快将成为 dev 的默认值）、即将推出的 cargo gc，以及在工作区内统一依赖 feature 的工具。
  • 对编译时间的体验分化很大：
    • 有些人表示真实应用的 release 构建要花 15–90 分钟，使 CI 和修改都很痛苦。
    • 也有人报告，即使是大型代码库，增量构建也只需不到 1 秒到几秒，并认为数分钟的构建时间说明项目架构或环境有问题（例如构建目录上的杀毒软件、庞大的依赖树、沉重的宏/泛型）。

Rust 与其他生态系统

  • 与 Python 和 Go 的比较强调了这些语言几乎没有“构建”时间，而 Rust 则不同。
  • 有人回忆把 Python 重写成 Rust 后获得了巨大的运行时提速，从而证明较慢的编译是值得的。
  • 也有人认为，较长的编译时间在运维中是个负担（例如重建导致故障恢复延迟），并且让 Go/Zig 尽管有取舍仍然具有吸引力。
  • 讨论指出，泛型/单态化和 derive 宏本质上就会消耗编译时间，不像 Go 那种更动态的分发模型。

语言演进与替代方案

  • 一些人认为 Rust 的未来光明，而且它其实已经是“现在”了（Linux 内核、Windows、浏览器）。
  • 持怀疑态度的人预测，未来会出现一种结合 Go 式简洁、Zig 式编译速度和 Rust 式安全性的语言，语法甚至可能类似 Lisp。
  • 还有人提到 OCaml 和基于 GC 的系统编程在某些领域也是可行的替代方案。

编译器路线图与工具链

  • 大家对新的 trait 求解器、Polonius，以及长期停滞功能（如 specialization 和与 async 相关的改进：Return Type Notation、trait 中的 async 函数）的进展感到兴奋。
  • 讨论了 polymorphization 作为减少代码重复的一种方式；基础形式可能会默认启用，而更激进的形式则用于调试/尺寸优化构建。
  • rust-analyzer 的持久缓存依赖 Salsa 上的工作；相关支持已经存在，但仍属初步阶段，且尚未成为优先事项。
  • 有人简短地问到在 LLM 重度介入的未来里 Clippy 的角色；共识是它仍然会有用。