在 5 月 14 日，PR #30412 合并到了 Bun 的主分支：超过一百万行 Rust 代码，6,755 次提交，几乎完全由 Claude Code 代理生成，持续了九天。收购 Bun 的 Anthropic 提供了这些代理。支撑 Bun 的 Zig 实现已经消失。Jarred Sumner 自己的话 - "我们已经几个月没有自己编写代码了" - 成为大家引用的部分，这也是将常规合并转变为 685 个点的 Hacker News 讨论主题的原因，PR 本身也在支持和反对的声音之间几乎平均分配。Rust 重写通过了现有测试套件的 99.8%。这个数字非常庞大且具有重要意义，但我们要精确说明它实际上所表达的：它表明新的实现行为与旧的实现一致，在运行时的公共接口上就是这样。仅此而已。并不意味着新的实现是安全的，也并不意味着它更好，甚至不意味着它是好的。这些都是不同的主张。基准测试表现中立或更快，二进制文件缩小了几兆字节（例如，Linux 上 x64 的起始点约为 93MB）。如果这就是全部故事，那么就没有什么好补充的：我想这会是一个 "好的合并"，因为 "更小" 和 "更快" 同时不会失去测试验证是 "好的属性"。但实际说明的原因并不属于这些原因，这表明这里的内容比人们所想的要多，大家都被对 Rust 的迷恋所蒙蔽 - 这种迷恋我也是 - 以及对 LLM 是否能够做到这种事情的兴趣。所声称的理由是安全性，Sumner 一直以来都表示动机并不是性能。Zig 的代码库让团队花费了数年时间来调试内存错误 - 使用后释放、双重释放，通常的潜在错误游行 - 而 Rust 的提议是借助编译器来实现内存安全。捕获在编译时 Zig 和 C、C++ 留给程序员的错误类别。这是一个有条理且值得尊重的理由去迁移。事实上，这似乎是大多数大型系统项目在选择 Rust 时所引用的共同原因。但是：重写版本在 700 多个文件中包含了超过一万个不安全的代码块。为了了解规模：uv，来自同一生态系统的一个大致可比规模的 Rust 项目，包含 73 个不安全代码块。这不是四舍五入的差异。这是两个数量级的差异，是移植策略的直接后果。团队发布了一份移植指南，指示代理忠实地翻译 Zig - 同样的架构、相同的数据结构，逐个文件。忠实的人工内存管理的移植在迁移过程中不会变得内存安全。它变成了一个穿着 Rust 面具的手动内存管理。每当 Zig 代码做了一个借用检查器会拒绝的事情，翻译就会采用不安全代码，而借用检查器正好在应该产生最大好处的地方退却。Todd Smith 对我评论说，他们本可以不这样失败；他们可以使用护栏说明 "不能使用不安全代码"，并添加一个 Git 提交前钩子以真正禁止它。在这种限制下，好的 LLM 会和他们一起工作，逐步增加内存安全性，但即便如此，这也需要审查：正如 Todd 所说，这是一个表面上看起来不去尝试这样的移植的合理理由。所以 99.8% 的测试通过率与超过 10,000 个不安全引用完全不矛盾。它们是同一事实的两种视角。测试套件通过是因为移植忠实。不安全的计数较高是因为移植忠实。忠实性是目标，而忠实性已经实现。没有实现的 - 也无法通过忠实的翻译实现 - 是这个整个工作作为理由的安全属性。你可以有一个忠实的移植，或者你可以有地道的安全 Rust。第一种是 LLM 逐文件翻译出的结果。第二种是内存安全论证所承诺的。它们不是同一工件，测试套件无法区分它们，因为在公共接口上的行为等价对底层字节是否健全是盲目的。 为什么这不是一个清理问题 自然的辩护是，这还早。这仅仅是金丝雀版本；后续 PR 即将到来；不安全计数会随着团队向地道 Rust 的重构而减少。也许是这样！但这里值得诚实地谈谈 “清除不安全的代码” 实际上意味着什么，因为这不是一项琐事 - 这是一个开放的研究问题。验证不安全的 Rust 是健全的难度相当大，以至于亚马逊召开了一项由 Rust 基金会主持的社区努力，专门验证标准库中的不安全代码 - 这是一个比一百万行代理生成的运行时代码体量小得多、审查得更严格的人工编写的代码体。这个努力的存在是因为不安全代码重新打开了未定义行为的门，而在不安全代码块中的一个错误将使周围所有内容的类型系统保证失效，Todd Smith 很久以前对我提到这一点。