用 Rust 重写 Bun

原文 ↗ Hacker News 讨论 ↗

重写背景与过程

  • Bun 主要通过 Anthropic 的 Fable 模型和 Claude Code，从 Zig 移植到 Rust，历时约 11 天，使用了 50+ 个自动化工作流和大量测试套件。
  • 这次重写被描述为主要是机械式的、按函数逐个迁移，在保留结构和数据模型的同时，再通过对抗式 AI 评审和人工监督进行迭代优化。
  • Rust 版本自 6 月中旬以来已经在 Claude Code 的生产环境中运行，未出现明显灾难性故障；一些人认为这已经构成了很强的验证。

成本与经济性

  • Token 消耗约为 59 亿未缓存输入、720 亿缓存输入、6.9 亿输出 token，按 API 定价估算约为 16.5 万美元。
  • 许多人认为这比一个小团队花上一年时间更便宜、更快；也有人反驳说，人类团队（尤其是在高成本地区之外）或能力较弱/更便宜的模型，可能以更低的总成本达到类似结果。
  • 也有人指出，即便现在这很贵，类似重写今后很可能会便宜得多。

代码质量、安全性与可维护性

  • 报告中的收益包括：修复了内存泄漏、崩溃更少、二进制体积缩小约 20%（配合链接器优化）、性能提升约 5%。
  • 支持者认为，Rust 的保证、编译器错误以及 Miri/内存工具，比 Zig 加上风格指南提供了更强的安全性。
  • 批评者强调大量 unsafe 使用（早期约有 1.3 万处）、Miri 最初发现了未定义行为，并认为许多 unsafe 块以及薄弱的 SAFETY 注释说明 Rust 不变量被误解了。
  • 对于在如此规模下由 AI 生成的代码究竟是否真的“可维护”，还是只是通过测试看起来稳定，双方存在分歧。

对 Zig 与语言争论的影响

  • 一些人认为这对 Zig 的观感不利：看起来从它“天真地”迁移出去后，稳定性和体积都得到了改善。
  • 另一些人强调，Bun 的 Zig 代码是在一个仍在演进、尚未 1.0 的语言上编写的，而通过收紧 Zig 代码和工具链，也可能取得类似收益。
  • 很长的子讨论围绕 Rust、Zig、C/C++ 和带 GC 的语言，在安全性、易用性、编译时间以及作为 LLM 目标语言的适配性上展开争论。

AI 工具、“vibe coding” 与工作的未来

  • 许多人将此视为在强大、语言无关的测试套件支撑下，LLM 辅助大规模翻译的一个展示案例。
  • 一些人把这个过程称为“vibe coding”（即由 LLM 驱动、而非经过穷尽的人类审查）；另一些人则认为，有测试保障的翻译不同于不受约束、带有猜测性的 AI 开发。
  • 人们普遍担忧这类能力对软件岗位意味着什么，尤其是中阶职位；也有人预计会出现 Jevons 式效应（产出更多软件，而不是更少工程师）。

项目治理与社区关切

  • 几位评论者批评这次重写的沟通和合并方式：
    • 早期表示 Rust 分支可能会被丢弃，但之后却很快合并。
    • 没有针对 Zig 线提供 LTS 或安全修复计划，实际上迫使用户升级。
    • 给人的印象是，Bun 更多受到 Anthropic 的营销和内部需求驱动，而不是外部社区。
  • 支持者回应说，合并前的代码本来就应该比较粗糙，回归问题已经被记录并修复，而且就用户而言，结果到目前为止是正面的。