Theo 谈 Bun 借助 AI 重写 Rust 的进展与风险

Bun 对我意义非凡。我从开始做内容时就认识了它的创始人 Jarred Sumner，一直支持这个项目，也见证了它被 Anthropic 收购。但最近我发现，使用 Bun 变得更困难了。OpenCode 的 Dax 正在转向 Node.js，原因包括 Windows 稳定性、Electron 集成，以及 Bun 未来方向的不确定性。

现在，Bun 正在借助 AI 智能体从 Zig 移植到 Rust。Jarred 表示，在使用 glibc 的 Linux x64 环境中，原有测试套件有 99.8% 通过了。起初只是一个实验，现在看来足够可行；录制这期视频时，我预计它会合并并发布，但这是我的预测，不是说它已经发生。

这次尝试提供了不少关于用 AI 迁移软件的经验。但人们对 Bun 的一些担忧，换一种语言未必能解决。为了理清这次移植，我想分别讨论 Zig 的问题、Bun 作为产品的问题，以及重写大型系统的风险。

Zig 很强大，它的编译期功能能让开发者以实用的方式控制生成代码，尤其适合跨平台系统集成。但强大的底层工具也会带来犯错的空间。手动管理内存可能造成泄漏、崩溃或安全问题，支持多个操作系统又增加了一层难度。

我自己也在 Bun 遇到过内存相关问题，早期版本尤其如此；Windows 更是反复让我受挫。Bun 可以把 JavaScript 和运行时打包为独立可执行文件，方便工具分发，但采用这种方式的应用也可能继承其平台问题。

OpenCode 的迁移之所以繁琐，部分原因是它使用了 Bun.file 等 Bun 专属 API。Bun 也支持 Node API，但依赖专属接口的代码要改写才能在其他运行时运行。Jarred 问过 Bun 1.3.10 之后 Windows 稳定性是否改善；以我的经验，问题仍然存在。

Dax 列出的理由不止 Windows。Node 可以嵌入 Electron 桌面应用，无须另起进程；支持 Node 也让其他应用更容易嵌入 OpenCode，并为探索 Deno 留出空间。他们自己的基准测试显示，Bun 的速度优势没有实质性改善他们的工作负载。

Bun 的包管理和打包能力可能非常出色。它的网站还展示了一项 Express 基准测试：Bun 每秒约处理 6 万个请求，Node 约 2 万个。对这项特定服务器测试来说，差距很明显，但这并不能说明本地编程智能体是否会受益。应该衡量自己的应用实际执行的工作。

William Johnson 的文章提出了另一层担忧。Anthropic 于 2025 年 12 月收购 Bun，并表示项目会继续以 MIT 许可证开源，由原团队继续开发。Claude Code 使用 Bun，因此 Anthropic 有动力维护它；但 Johnson 担心，整个生态的需求未必都与 Claude Code 的优先事项一致。

我也有类似的焦虑。我的判断是 Claude Code 的产品体验变差了，而 Anthropic 自己的事后分析也讨论过默认推理力度降低、会话状态过期以及提示词改动等问题。这些经历不能证明 Bun 也会变差，却让我开始质疑未来会如何做产品决策。

问题并非 Bun 不好，也不是团队不再关心它。我担心的是，随着团队进一步融入 Anthropic，影响 Claude Code 的问题可能比其他用户的问题得到更高优先级。我在包管理上也遇到了足够多的边缘问题，以至于考虑让 T3 Code 换掉 Bun。

假设目前有 10 个问题，一部分在 Claude Code 使用的运行时路径中，另一部分涉及 monorepo 包管理。如果重写后出现更多问题，不在公司主要使用场景中的问题能得到同样的关注吗？这些数字只是用来说明问题的假设，并非实际缺陷数量。社区分支听起来很有吸引力，但长期维护如此复杂的运行时非常困难。

Jarred 介绍说，移植后的大量代码基本相同，但 Rust 可以帮助约束生命周期，并在需要时提供析构机制。他说自己厌倦了花时间处理内存泄漏、崩溃和稳定性问题，希望获得更强的预防工具。我猜，管理更多人员和智能体后，持续关注每个底层细节变得更难；这是我对他动机的解读。

他说这次移植涉及约 96 万行代码，而他在六天前才开始工作。他还计划详细介绍过程、性能、内存使用和可维护性。这些都是视频录制时他的说法和计划；测试结果令人鼓舞，但范围限于所述平台和测试套件。

Bun 的 Zig 分支还加入了并行语义分析和多个代码生成单元，团队表示这让调试构建更快。Jarred 说，如果 Rust 移植最终合并，Bun 1.3.14 可能是最后一个 Zig 版本。这个条件很重要：通过测试的移植并不自动意味着可以发布。

Charlie Marsh 提出了关键问题：团队会不会用已知问题换来数量未知的新问题？再好的测试套件也只能覆盖部分程序行为。Jarred 表示，重写版通过了与 200 多个问题相关的测试，他还没看到它比 Zig 版更慢的基准测试；这些观察仍需要更广泛的验证。

这次移植旨在保留现有实现，只使用少量第三方库，也没有全面采用 async Rust。Rust 的所有权和借用规则可以帮助安全代码避免某些内存错误，但它们不能消除所有错误或内存泄漏；使用 unsafe 时，程序员还必须满足额外的安全条件。

我把 unsafe 的使用情况当作一个粗略信号。在用 Rust 构建的 uv 项目里，第一次搜索找到 165 处，其中包括注释；换成某一种 unsafe 代码块的特定写法后，结果约为 73 处。这只是粗略的文本搜索，不同搜索模式无法可靠比较所有 unsafe 操作。

我在 Bun 移植版中搜索到 13,044 处 unsafe 字样。这是文本匹配数，并非经过核实的 unsafe 块或缺陷数量。我关注它，是因为紧贴低层 Zig 实现的翻译可能把原有假设带入 Rust，而不会立刻变成符合 Rust 惯例的安全代码。仅凭这个数字无法判断代码风险。

一种可能的路径是找到有问题的 unsafe 函数，理解它依赖的安全约束，再逐步用安全抽象替换其中的部分代码。智能体可以利用编译器诊断作为反馈。但通过编译只是有用证据，不能单独证明迁移后的行为完全正确，也不能证明周围所有 unsafe 假设都可靠。

TypeScript 团队将编译器移植到 Go 的过程提供了一个可供比较的例子。最初的做法尽量贴近原有实现，即使结果不符合 Go 的惯例，也能借助原生可执行文件获得速度提升。此后再进一步优化，发挥 Go 的长处。先保留行为，可以是一种务实的迁移策略。

这改变了我对语言的看法：语言可以是生成可执行程序的工具，而不是团队必须完全认同的身份。Bun 团队热爱 Zig；Rust 提供的工具则可能有助于解决他们想处理的错误。AI 能让重复性的移植工作更可行，但测试、测量和人的判断仍然必不可少。

Jarred 还描述了一个棘手的分层问题。把移植版拆成许多 Rust crate 有助于编译，也可能让组件更容易复用，但 crate 边界不允许循环依赖。Bun 的 Zig 代码在事件循环任务、进程退出回调和非阻塞文件 I/O 等接口中使用了带标签指针。

他担心特定 trait 或函数指针方案的开销，以及编译器在这种设计下能否对其进行优化。当前方案使用生成的声明和链接时优化，在可能的情况下把带标签的分派变成直接调用。他向有经验的 Rust 开发者征求更简洁、运行时和内存开销都很低的方案；这是具体的工程权衡，不是对所有 Rust trait 的普遍结论。

即便智能体能快速生成代码，编译时间、模块边界和底层性能仍然是难题。Jarred 一边学习，一边公开讨论设计。我尊重这个实验的雄心，但移植规模和大量 unsafe 用法也让仔细审查变得重要。

Jarred 表示，只有 Rust 版在性能、内存使用和稳定性方面都比 Zig 版有可测量的改善，他才会合并它，其中稳定性是首要任务。我信任他，也希望团队成功。录制时我预计它既会带来好处，也会引入新问题；结果还有待观察，而这次尝试会让我们学到很多。