聊一聊 Bun 用 Rust 重写这件事

Bun 的这个 PR 合并以后很多人第一反应是又一个 JavaScript runtime 投向 Rust 了。这个反应不奇怪。Deno 最早是 Go 写的后来换成 RustBun 原来是 Zig 写的也切到了 Rust。我就是在 Deno 用 Rust 重写的时候一边学 Rust 一边给 Deno 修 bug 的所以看到 Bun 这次迁移多少有点熟悉的感觉。不过这篇文章不想写「Rust 赢了」「Zig 输了」。我更想聊的是另一件事Bun 这次最大的看点它展示了一种未来软件开发会越来越常见的方式用 AI 参与一个庞大真实产品的跨语言迁移。PR #30412 的标题就是Rewrite Bun in Rust已经在 2026 年 5 月 14 日合并。规模很大6755 个提交2188 个文件变更新增代码超过 100 万行。PR 作者 Jarred 后来补充了一段说明比一开始的信息更完整• 已经通过 Bun 既有测试套件的全平台测试。• 顺手修了一些内存泄漏和 flaky testsRust 最擅长的领域。• 二进制体积缩小了 3MB - 8MB。• benchmark 结果从持平到更快。• 代码库整体上还是同样的架构、同样的数据结构。• Bun 仍然很少使用第三方库也没有改成 async Rust。• 想试的话可以跑bun upgrade --canary。这段说明很关键。它告诉我们这并非「生成了一堆 Rust 文件还没跑起来」的状态。至少按作者的说法Bun 已经把这次迁移推进到了 canary 可以试用的阶段。但作者也保留了边界进入非 canary 版本之前还有优化工作清理会在后续 PR 里继续做。如果只看语言选择这件事很容易和 Deno 放在一起讲。Deno 从 Go 换到 RustBun 从 Zig 换到 Rust。两个项目都在 JavaScript runtime 这个方向上最后选择了 Rust 作为底层实现语言。这当然说明 Rust 在这类系统软件里的吸引力很强性能、内存安全、工具链、生态、跨平台能力都很适合这类项目。但 Bun 这次比「换语言」更有意思。Deno 当年换 Rust本质上还是一个比较传统的软件工程迁移。人读代码人写代码人修 bug。Bun 这次发生在 AI 编程工具已经比较成熟的阶段它的仓库里出现了PORTING.md和大量.claude/workflows它更像是把迁移过程拆成一条流水线。PORTING.md里有一个很重要的设定Phase A 先把 Zig 文件翻译成同目录下的 Rust 草稿目标是忠实捕捉逻辑不要求马上编译Phase B 再按 crate 去解决编译、所有权、平台和性能问题。这和很多人想象的 AI 写代码不一样。不是对模型说一句「帮我把 Bun 改成 Rust」然后等一个奇迹。真正有用的是先把迁移规则写清楚再让 AI 按规则批量执行。比如哪些库不能引入哪些架构不能动哪些类型不能乱换哪些 allocator 语义要保留哪些 unsafe 边界只是从 Zig 世界搬到了 Rust 世界。规则越细AI 越不容易自由发挥。这也是未来软件开发里很重要的变化。以前开发者主要产出代码以后在很多大型工程里开发者的一个重要产出会变成「约束」。你写的不只是代码还有• 迁移手册。• 类型映射规则。• 测试策略。• review 标准。• CI 检查。• 不允许改变的架构边界。Bun 这次的.claude/workflows很能说明问题。有的工作流负责把 Zig 文件翻译成 Rust 草稿有的负责对照规则做验证有的负责修复有的负责 lifetime 分类有的负责 unsafe audit有的负责 Windows bughunt。以前的流程是「AI 帮我补一个函数」了现在的流程是「AI 参与一个跨语言、跨模块、跨平台的工程迁移」。我觉得这会对未来的软件开发产生很大影响。很多以前太贵、不敢动的迁移可能会重新进入工程选项。老 C/C 模块迁到 Rust大型脚本工具链的热点部分迁到 Rust内部 DSL 迁到更标准的语言甚至多年没人敢碰的遗留服务做结构化重写都可能因为 AI 的加入变得没那么离谱。当然没那么离谱不等于没风险。跨语言迁移最难的地方从来不是语法。Zig 里的很多东西靠 allocator、deinit、comptime、手写指针结构和项目约定维持。Rust 可以用 Drop、借用检查、类型系统、lint、工具链接住一部分问题但前提是映射正确。如果只是把*T改成一个看起来更 Rust 的类型那可能只是把 bug 包装得更现代。所以 Jarred 那句「架构和数据结构基本保持不变」很重要。它说明这次迁移是在尽量保持原来设计的前提下用 Rust 重新表达它。这件事真正有价值的部分是 Bun 团队希望拿到 Rust 编译器和工具链对内存问题的辅助。作者也说了这类内存 bug 过去几年消耗了团队大量开发和调试时间。AI 写代码越快静态约束就越重要。如果没有编译器、类型系统、测试和规则文档夹住它AI 只是把错误生成得更快。反过来如果一个项目有清晰的边界、比较完整的测试、可机器读取的规范AI 就有机会变成高吞吐的工程劳动力。我觉得这件事更像是一个信号未来的软件开发会变成三层。第一层是 AI 负责吞吐。生成草稿、批量迁移、扫明显问题、跑自动验证。第二层是工具负责约束。编译器、类型系统、lint、测试、CI、benchmark把问题尽量提前暴露。第三层是人负责判断。哪些结果可信哪些地方必须手工看哪些行为不能改哪些风险可以接受哪些问题必须阻断发布。开发者不会消失但位置会变。过去我们常说「程序员写代码」。以后更准确的说法可能是程序员设计一个能让 AI 安全工作、能让错误尽早暴露的工程系统。现在很多社区都开始讨论这件事然而这些讨论里低质量的部分很多。比如「Zig 完了」「Rust 赢麻了」「AI 写的都是垃圾」。这类说法很适合吵架不太适合帮助我们理解发生了什么。真正值得看的问题是• 这么大的自动迁移怎么 review• 原来的 Zig 语义Rust 版本有没有真的表达出来• 测试通过以后还需要多少 canary 覆盖• 平台差异、性能路径、FFI 边界会不会在真实项目里暴露问题• 如果后续有 bug团队能不能快速定位和修复这些问题比语言站队重要。最受开发者关注的是性能。官方说 benchmark 从持平到更快这当然是好消息。但具体到你的项目还是要用自己的真实工作负载测。冷启动、安装依赖、构建、热更新、服务端请求路径哪个关键测哪个。我看 Bun 这次迁移最大的感受是AI 会改变软件开发里的很多流程和假设。以前一个项目太大那么就很难重写。现在如果有足够清楚的规则、测试和工具AI 可能先把第一版迁移成本降下来。它不保证成功但它让「试一试」的成本变低了。这会改变团队做技术决策的方式。很多过去因为人力不够而长期拖着的问题可能会被重新评估。团队会更愿意问如果 AI 能先生成 70% 的可审查草稿我们是不是可以做这次迁移但最后还是那句话AI 不会替你承担生产责任。它可以写代码可以翻译代码可以帮你跑一轮 review。但架构边界、发布节奏、兼容性判断、线上问题的责任仍然在人这边。Bun 用 Rust 重写完成这件事最有意思的地方就在这里。它是一次很公开的工程实验当 AI 能参与大型代码迁移以后软件开发会变成什么样。资料来源• GitHub PRoven-sh/bun#30412 - Rewrite Bun in Rust• 早期 porting guide 提交46d3bc29 - docs/PORTING.md• GitHub 合并提交23427dbc• Deno 背景Deno was initially written in Go, later replaced with Rust• HN 讨论Bun implementation is being ported from Zig to Rust• Ziggit 讨论Bun is being ported from Zig to Rust