Bun 已经被转换为 Rust。接下来呢？

原文 ↗ Hacker News 讨论 ↗

Rust 移植的感知目标与结果

  • 主要声明的好处：从 Zig 迁移到 Rust，同时保持行为不变，并且大多数测试仍然通过。
  • 有些人看到确实的收益：构建更简单、对 unsafe 代码的使用有明确标注、以及逐步加固的潜力。
  • 另一些人认为这次重写在很大程度上只是形式上的，或者是营销噱头，尤其是在仍然存在不安全性并且有 LLM 参与的情况下。
  • 还有少数人指出，接近中性到更好的基准测试和更小的二进制文件，是有意思的 Zig 与 Rust 数据点。

unsafe 的使用与内存安全

  • 核心担忧：数以万计的 unsafe 块，其中许多由 LLM 生成，削弱了 Rust 关于内存安全的核心承诺。
  • 支持者认为，明确标记的 unsafe 本身就比 Zig/C 更好：你会得到一份具体的“待修复”清单。
  • 批评者反驳说，只要其中有一个块不安全，整个程序就可能出现未定义行为；在有“无数”LLM 编写的块的情况下，这种风险很高。
  • 对比：据说 Bun 的 unsafe 密度大约是 Deno 的两倍，不过两者都必须包裹不安全的 C/C++ JS 引擎。

LLM 驱动的“vibe coding”与信任

  • 对是否应该信任一个主要由 LLM 翻译出来的运行时，存在强烈分歧：
    • 一些人认为：带着良好测试套件的翻译，是 LLM 最好的用途之一。
    • 另一些人认为：运行时是基础设施；发布一百万行主要由 AI 编写、几乎没人读的代码，“显然是不负责任的”。
  • 关于“vibecoding”这一标签的争论：有人认为它抹平了工具与流程之间的细微差别；另一些人把它当作低严格度使用 AI 的简写。
  • 还有人担心，对 AI 的高度依赖会侵蚀开发者判断代码质量的能力。

测试、正确性与安全性测量

  • 普遍认同高测试通过率只能证明行为等价，并不能证明内存安全。
  • 有人指出，在移植过程中测试套件本身也被调整过，因此精确的“99.8%”数字有些不清楚。
  • 强调测试无法覆盖所有失败模式；深入理解与审查仍然是必需的。

流程、惯用 Rust 与未来工作

  • 许多人怀疑，一个为期一周、百万行的 PR 根本不可能被认真审查。
  • 担心结果是不符合惯用写法的 Rust，却保留了 Zig 风格的内存语义，使长期重构更困难。
  • 有些人认为，现在真正的工作是进行大量、谨慎的重新架构以移除 unsafe；另一些人则怀疑，重新设计一个全新的 Rust 方案可能比直接移植更好。