Bun 已转换为 Rust。接下来怎么办？

# Bun 已转换为 Rust。现在呢？ 来源：https://bytecode.news/posts/2026/06/bun-has-been-converted-to-rust-now-what 5 月 14 日，PR #30412 (https://github.com/oven-sh/bun/pull/30412) 合并到了 [Bun](https://bun.sh/) 的主分支：超过一百万行的 [Rust](https://rust-lang.org/) 代码，6,755 次提交，几乎完全由 Claude Code 代理在九天内生成。收购了 Bun 的 Anthropic 公司在去年 12 月提供了这些代理。驱动 Bun 的 [Zig](https://ziglang.org/) 实现已经消失。Jarred Sumner [自己的话](https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/)——“我们已经好几个月没亲自打字写代码了”——是大家引用的部分，也正是这句话，让一次常规的合并变成了一场 685 点的高峰 Hacker News 讨论 ([thread](https://news.ycombinator.com/item?id=48132488))，PR 本身的赞同与反对票数几乎持平。 Rust 重构版本通过了 99.8% 的现有测试套件。这个数字*巨大*且*意义重大*，但我们要精确地理解它实际说明了什么：它表明新实现在运行时的公共接口上表现得像旧实现一样。仅此而已。它并没有说新实现是安全的、更好的，甚至*好的*。这些是不同的论断。 基准测试结果持平或略快，二进制文件缩小了几兆字节（例如，在 Linux x64 上起始大小约为 93MB）。如果故事就此结束，那就没什么可补充的了：我想，这可以算作一个“好的合并”，因为“更小”和“更快”且不损失测试验证是“好的属性”。但实际陈述的理由*并非这些理由之一*，这表明背后还有更多东西，而人们被对 Rust 的迷恋（我也同样迷恋）以及对 LLM 能否完成此类壮举的兴趣所蒙蔽，忽略了这一点。 ## 陈述的理由是安全性 Sumner 一直坚持动机不是*性能*。Zig 代码库让团队花费了数年时间调试内存错误——释放后使用、重复释放，以及一系列常见的潜在错误——而转向 Rust 的提议是编译器辅助的内存安全。在编译时捕获 Zig（像 C 和 C++ 一样）留给程序员的这类错误。这是一个合理且值得尊敬的迁移理由。事实上，这似乎是大多数大型系统项目在转向 Rust 时引用的*常见*理由。 但是：重构版本包含超过一万个 `unsafe` 块 ^1 (https://bytecode.news/posts/2026/06/bun-has-been-converted-to-rust-now-what#fn-1)，分布在 700 多个文件中。作为对比：`uv`，一个来自相似生态领域、规模大致可比的 Rust 项目，只包含 73 个。这不是四舍五入的差异，而是两个数量级的差距，这是移植策略的直接后果。 团队发布了一份移植指南，指示代理忠实地翻译 Zig——相同的架构，相同的数据结构，逐文件进行。手动内存管理的忠实移植不会在过程中变得内存安全。它变成了戴着 Rust 面具 ^2 (https://bytecode.news/posts/2026/06/bun-has-been-converted-to-rust-now-what#fn-2) 的手动内存管理。每当 Zig 代码做了借用检查器会拒绝的事情时，翻译就会求助于 `unsafe`，而借用检查器恰恰在它本应发挥最大作用的地方退却了。 > Todd Smith (https://github.com/toddATavail) 对我评论说，他们甚至不必以这种方式失败；他们可以使用保护机制说“你不能使用 `unsafe`”，并添加一个 `git` 预提交钩子来真正禁止它。在这样的限制下，一个优秀的 LLM 会与之合作，在过程中增加内存安全性，但这仍然需要审查：正如 Todd 所说，这本身就是不尝试此类移植的一个很好的理由。 因此，99.8% 的测试通过率和超过 10,000 个 unsafe 引用并不矛盾。它们是同一事实的两个方面。测试套件通过*是因为*移植是忠实的。`unsafe` 数量高*是因为*移植是忠实的。忠实是目标，忠实也达成了。没有达成的——通过忠实翻译无法达成的——是整个工作本应用来证明的安全属性。 你可以有忠实的移植，或者有地道且安全的 Rust。前者是 LLM 逐文件翻译产生的。后者是内存安全论点所承诺的。它们不是同一件产物，而测试套件无法区分它们，因为公共接口上的行为等价性无法察觉到底层的字节是否健全。 ## 为什么这不是一个清理问题 自然的辩护是，这还处于早期。这只是个雏形；后续的 PR 会跟进；随着团队转向地道 Rust 进行重构，`unsafe` 的数量会降下来。也许如此！但这里值得坦诚地思考“重构掉 unsafe”实际上意味着什么，因为它不是一项杂务——而是一个开放的研究问题。 验证 unsafe Rust 的健全性已经足够困难，以至于亚马逊召开了一个由 Rust 基金会主办的社区行动 ([合作](https://foundation.rust-lang.org/news/rust-foundation-collaborates-with-aws-initiative-to-verify-rust-standard-libraries))，专门用于验证*标准库*中的 unsafe 代码 ([verify-rust-std](https://github.com/model-checking/verify-rust-std))——这是一个规模小得多、审查严格得多、由人类编写的代码库，而非百万行由代理生成的运行时。这个行动之所以存在，是因为 unsafe 代码重新开启了未定义行为的大门，而 unsafe 块中的单个错误会使周围的一切类型系统保证失效，这是 Todd Smith 很久以前向我提出的观点，也是在使用 Rust 时*非常*值得注意的一点 ^3 (https://bytecode.news/posts/2026/06/bun-has-been-converted-to-rust-now-what#fn-3)。 仅标准库就产生了超过二十个可追溯到 unsafe 代码的 CVE ([论文](https://arxiv.org/abs/2510.01072))，尽管经过了数十年的专家审视。验证 unsafe Rust 的学术前沿是半自动化工具和需要人类编写规范的概念验证验证器。目前没有一键式的“使这个 unsafe 块变得健全”的通行证，短期内也没有前景。 > Todd 基于对类似问题的大量研究给出的建议是：“根本不要自动移植内存不安全的代码。制定你所开发产品的宏观可观测表面的详细规范，然后告诉代理仅将现有代码作为指导，用于填充细节，同时主要根据规范行动。” 当然，这意味着你必须*拥有*一个良好的、完整的规范…… **这意味着从超过 10,000 个 unsafe 块到某种可辩护状态的道路，不是一次后续 PR。而是一项多年的审计工作，目标是比任何人阅读它的速度都更快生成的产物。** 生成可以规模化；验证则不能。这种不对称才是真正的新闻，而且它并非 Bun 所独有——Bun 可能只是迄今为止最大、最公开的一个实例。 ## 谁来审计这个？ 最热门的 HN 评论者所关注的问题不是“Rust 还是 Zig”，也不是“AI 是否应该编写运行时”。问题更窄，也更难以回避：*谁真正审查了代理在九天内交付的一百万行代码？* 诚实的回答似乎是，没有人以通常处理这种爆炸半径代码的方式阅读它，因为以它被编写的速度来阅读，不是人类能做的事。团队自身的信心依赖于测试套件——这又让我们回到开头，因为测试套件从未衡量过*转换的整个要点*。 有一个小小的、讽刺的尾声。删除大约 60 万行遗留 Zig 的后续 PR 被 Sumner 命名为“ai slop”。GitHub 的自动化反 slop 检测——正是为了标记这种 AI 生成的大规模变更而构建的——捕获了它并自动关闭了它。作者将自己的清理工作命名为 slop，而平台的工具也同意了。这也是当前验证层相对于生成层所处位置的最清晰的一句话描述：编写代码的机器现在远远领先于应该检查代码的机器，而人类则处于两者之后。 ## 这对你，具体意味着什么 所有这些都不是预测 Bun 会出故障。它可能完美运行多年；对工作代码的忠实移植通常能工作，这正是忠实性的全部意义所在。那 0.2% 未通过的部分由边缘情况和平台特定行为组成，而未定义行为不会自我宣告为一个失败的测试——它会在十八个月后，以一个在谁都没在 CI 中运行的特定 `libc` 上的 CVE 形式出现。（或者也许是某个路由器选用的奇怪 `musl`……）风险状况并没有在任何明显方面比 Zig 版本更差。它只是在重构被宣传为能够交付的*特定方面*没有变得*更好*，而现在一大堆积压的 `unsafe` 成为了一个工具下的承重基础设施，而按照 Anthropic 自己的说法，这个工具被内置于 Claude Code 中，服务于数百万用户。 实际结论不是“AI 不好”或“Rust 不好”。（Rust 实际上*很好*。AI 也一样，只要像任何其他工具一样负责任地使用。） 这是一种测量纪律：当有人向你提供一个测试通过率作为安全属性的证据时，*检查测试套件是否测量了该属性*。行为等价性和内存健全性是不同的维度。一个绿色的测试套件告诉你新东西表现得像旧东西。如果旧东西是一堆手动内存管理代码，而新东西是它的忠实翻译，那么绿色告诉你翻译是好的——而对于这个东西是否安全则完全没有说明。真正能回答这个问题的那个数字，目前还没有人能提供，因为生成它，就目前而言，还是一个未解决的问题。 这才是故事的核心，而不是那次合并。