“烂代码”转正？Bun稳定版终落地：跳票一个半月，2900个问题清零

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生成的代码如果缺乏工程监督，最终会