8 月 20 日，Bun 1.4 稳定版正式发布。

这是 Rust 重写后的首个稳定版本，也是 Bun 被 Anthropic 收购后的第一次大版本更新。距离上一个稳定版 1.3.14，已经过去 99 天——这也是 Bun 自 2022 年以来最长的稳定版本发布间隔。

开发者和技术作家 Simon Willison 将几个月前的 Rust 重写称为“臭名昭著”的实验。他还注意到，官方在 Bun 1.4 的发布说明中淡化了这次重写，主要篇幅都留给了数量庞大的新功能和 2900 项 Bug 修复。

这次重写意义重大，因为它被视为一场高风险的 AI 编程实验：如果 AI 能够在 11 天内完成大型生产级代码库的跨语言迁移，并最终被大多数社区用户采用，将为这种“全速 AI 编程”模式提供重要的现实证据，尤其是在大规模代码迁移项目中。

我其实暗暗希望它失败。这样，那些整天鼓吹“AI 将取代所有软件开发者”的付费水军，或许就能彻底消停了。

现在网上充斥着各种吹捧代码生成器的内容，有人说它们带来了革命性变化，还有人声称，借助这些工具，两个月就还清了过去五年积累的技术债。面对数万亿美元的利益牵扯，我们恐怕已经很难相信自己看到的任何说法。许多鼓吹者可能只是拿钱办事的水军。

暂且不谈那些功能和性能改进，如果它确实能够稳定运行，没有出现重大 Bug 或其他严重问题，那么未来几年，我们恐怕会看到管理层自上而下地推动一轮“用 Rust 重写”的浪潮。更糟的是，管理层甚至会开始相信“让 Claude 生成任务，再交给 Claude 开发”这套模式。

这件事早已不只关乎 Bun 或 Node.js。它已经成了 AI 编程与传统人工编程之间的主战场。

如今正式版已经交付，接下来还要接受真实项目的检验。

Bun 创始人 Jarred Sumner 还在今天的发布视频中提到：自 Bun 1.3 发布以来，Bun 被 Anthropic 收购，月下载量增长了四倍，突破 2000 万次。并且他还宣称 Bun 1.4 的发布让他们离“替代 Node.js”的目标“迈进了一大步”。

从“11 天写完”到“三个月交付” 

今年 5 月，Jarred Sumner 用 Claude Code 完成了一场轰动业界的实验：11 天内将 53 万行 Zig 代码迁移为 78 万行 Rust，API 成本 16.5 万美元，高峰时 64 个 Claude 同时运行。

然而，“写完”不等于“可以发布”。

Bun 最初宣布 1.4 将于 7 月 7 日发布。此后一个多月，Bun 官方和 Jarred Sumner 不断预告版本“马上到来”，实际发布日期却一次次落空。这些反复出现的空头承诺，也逐渐耗尽了社区的耐心。

Bun 1.4 的重写，是一次押注 AI 的豪赌。过去一个月里，robobun 提交了 1.58 万个 commit，autofix-ci[bot] 提交了 1600 个，Jarred 本人提交了 790 个。

截至 8 月 19 日，这个项目有超过 5000 个尚未处理的 Pull Request，数量十分庞大。Bun 1.4 发布后，这批积压也没有明显减少：截至 8 月 21 日，仍有 4993 个 PR 处于 Open 状态，AI 机器人还在持续提交新的 PR。作为对比，OpenClaw 有 2200 个，React 有 441 个。GitHub 建议，指向同一个分支的未合并 PR 最好不要超过 1000 个，否则可合并性检查可能开始超时。

那么这次发布主要变化是什么？

首先是新增功能。原来有些本应由运行时直接处理的任务，用户需要安装额外的软件包。Bun 1.4 把一些能力直接内置进运行时。Jarred Sumner 称，Bun 1.4 带来的内置功能比以往所有版本都多。其中包括一套图像处理库、无头浏览器自动化、终端控制、压缩包、定时任务、Markdown，以及原生 JSON5、JSONC 和 JSONL 解析等。

其中，Bun.Image 的设计受到 Sharp 启发，支持包括 AVIF、HEIC 和 WebP 在内的七种图像格式，并直接调用操作系统的原生 API，读取图像元数据的速度最高可达 Sharp 的 70 倍。

Bun.WebView 可以直接驱动 Chrome 和 Safari，打开网页、执行 JavaScript、截取屏幕截图，并以编程方式发送原始 CDP 命令，不需要安装额外依赖。Bun.serve 也开始支持 HTTP/3，单线程每秒可以处理超过 50 万次请求。

随后是稳定性和内存问题。Bun 1.4 修复了超过 2900 个 GitHub Issue，并清理了所有能够检测出来的内存泄漏。此前，在同一个进程中连续调用 Bun.build 2000 次，会泄漏数 GB 内存；Rust 重写后，这类泄漏已经被消除。

与此同时，得益于链接时优化，Bun 的整体性能还提升了 2% 至 5%，覆盖 HTTP、解析、打包和 JavaScript 执行等几乎所有环节。即便增加了 150 多项新功能，Linux 和 Windows 版本的二进制体积仍然缩小了 10MB 以上。

包管理、测试和构建能力也在同步推进。bun install 引入全局虚拟存储，通过符号链接让不同项目共享同一份软件包，安装速度最高提升至原来的 8 倍；同时改为将软件包直接以流式方式写入磁盘，使大型代码仓库的峰值内存占用最多降至原来的十七分之一。bun test 增加了并行测试、测试隔离和 Jest 假计时器三项呼声最高的功能。Bun.build 现在可以把整个前端项目编译成一个独立的 HTML 文件，通过内置方式运行 React Compiler 的速度比经由 Babel 调用快 19 倍以上。

Zig 创始人：重构版是“没人把关的烂代码” 

但 Bun 的快速开发是否违背了优质软件开发的核心原则？

Zig 公司的 Kelley 对此并不买账。此前，他在一篇题为“我对 Bun 用 Rust 重写的看法”的博文中，情绪激烈地表达了自己的疑虑。

Kelley 写道，甚至在 Anthropic 收购之前，“我们对在 Bun 代码库中看到的编程实践感到越来越震惊”。Bun 是使用 Zig 语言开发的规模最大、知名度最高的项目之一，在被 Anthropic 收购之前，它一直是 Zig 软件基金会的定期捐助者。

在 Kelley 看来，该项目激进地发布新功能，导致 Bug 堆积如山、错误处理代码拙劣，并积累了大量的技术债务。

Kelley 打趣道：“早在获得大语言模型（LLM）访问权限之前，Sumner 就已经在写一团糟糕的代码了。”他推测，Sumner 可能面临着必须达成商业目标而非技术目标的压力，而这种压力在被 Anthropic 收购后愈发加剧。

事实上，在 Kelley 看来，Bun 的代码库已经变得如此令人怀疑，以至于 Bun 与 Zig 分道扬镳反而是个好消息。他写道：“这个曾被公众视为 Zig 编程语言典范的项目，实际上已经是‘如何写出糟糕的 Zig 代码’的典型反面教材。”

Bun 团队还曾尝试将部分 AI 辅助开发成果回馈给 Zig 项目，但未果。在重写 Bun 之前，该团队维护着一个 Zig 分支，据称其调试编译速度提高了四倍。但 Zig 项目以“不接受基于 AI 的贡献”这一政策为由，拒绝了 Bun 的改动。

Zig 项目此前也收到过大量由大语言模型生成的代码贡献，其中大部分质量堪忧。Kelley 认为，AI 生成的代码如果缺乏工程监督，最终会留下大量问题。

Kelley 还对 Jarred Sumner 在重写博客中的部分叙述提出质疑。文章暗示 Bun 团队一直在认真地对 Zig 代码进行模糊测试，但 Kelley 称，Bun 团队此前与 Zig 方面沟通时曾明确表示，他们并未开展任何模糊测试。

他还质疑，既然 Bun 的测试套件没能发现原有 Zig 代码中的大量 Bug，又凭什么为上百万行未经人工审查的 Rust 代码兜底？

Kelley 写道：“支持一次性提交这 100 万行未经审查代码的理由，是测试套件足够完善，能够发现所有问题。可它连 Zig 代码中的 Bug 都抓不全，又怎么能抓住 100 万行未经审查的垃圾代码中的所有 Bug？”