2026年5月, Bun项目完成了一次代码迁移, 这次迁移在软件开发史上近乎罕见, 且大规模。
这次迁移启动于5月3日, 到5月14日正式合并入主分支, 仅仅用了11天, 写代码只用去6天, 且整个过程是公开的, 但Jarred Sumner写博客总结却花费了快一个月, 比写代码的时间长得多。
该JavaScript运行时, 原本存有535,496行Zig代码, 此为不包含注释的情况；并且, 约20%的代码乃是由C++编写, 还嵌入了多个C/C++库。这次借助AI将其重写为Rust, 整个过程涉及超过100万行代码变更, 有6778次提交, 还在Claude Code中运行了大约50个动态工作流。
依据Sumner所披露的数据, 此次重写, 在API层面, 耗费了59亿个未被缓存的输入token, 涉及到6.9亿个输出token, 还有720亿个缓存输入token的读取, 按照API定价来计算, 大约花去了16.5万美元。
Sumner讲, 这是当下技术能够抵达的前沿水准他估量, 要是让三名对Bun代码库全然熟悉的工程师靠手工去实施这次迁移, 大概需要一年时长, 并且在这一年当中, 团队几乎不能持续推动新功能开发、bug修复以及安全修复。
经此次重写后, Bun v1.3.14 变为最后一个 Zig 版本, Bun v1.4.0 会成为第一个 Rust 版本。
1 成果：从 6.7GB 内存泄漏到 609MB 稳定
Bun开始是个Zig项目, 其覆盖面极为广泛, 它身为JavaScript与TypeScript转译器, 同时还是打包器、包管理器、测试运行器、模块解析器、HTTP以及WebSocket客户端, 并且实现了Node.js API层。正是这样的产品宽度, 使得Bun的CLI月下载量超出2200万次的数量, 并且获得Vercel的支持, 获得Railway的支持, 获得DigitalOcean的支持, 获得Claude Code的支持, 获得OpenCode等项目或公司的支持。
但同样是这种宽度，也给 Bun 带来了一些挑战。
尤其在Bun v1.3.14里, 存在一个令众人苦恼许久的状况, 即当接连不断地执行Bun.build()调用之时, 内存会持续地积聚开云app在线入口，并且从不释放。每一次构建大概泄露3MB, 看起来数量不算多, 然而要是你运行的是一个开发服务器, 每一次请求都会引发一次构建, 那么内存就会被逐渐地消耗, 直至进程崩溃。
实际进行测试时, 执行构建, 达到500次后, 内存占用为1.9GB, 当执行次数达到1000次后, 内存会变化为3.5GB, 当处于1500次构建之后, 内存占用变成5.1GB, 若执行了2000次, 内存会突然大幅上升到6.7GB。
这仅仅是众多内存相关问题里极为微小的一部分, 于 v1.3.14 的错误修复清单当中, Sumner 罗列出 了一连串的问题:
存在这样一些显而易见特别突出的共性是有关于这些bug的, 它们之中的几乎每一个都朝着同一个根源去指向, 这个根源便是在同一个软件当中把GC和手动内存管理进行混合使用。
面对JavaScriptCore（还有V8）这般的现代引擎, 其针对异常处理与GC有着极为严格的规则, 然而Zig如同C语言是不会自动去管理内存的。当这两种范式处于同一个进程当中的时候, 每一个内存分配都得做到逐行去审查如下这些问题: 这些字节究竟是在何处被释放的? 要怎么才能够确保仅仅释放一次? 有没有正确地检查JavaScript异常？这个由GC管理的指针对于保守栈扫描器而言是否可见? 这到底是GC内存还是手动管理的内存?
更让人焦虑的是, 团队并非没付出努力。他们针对 Zig 编译器做了修改, 添加了 Address Sanitizer 支持（ASAN）, 每次提交均在 CI 里运行 ASAN 测试, 于 Windows 上采用 ReleaseSafe 构建, 借助 Fuzzilli 施行 24/7 的模糊测试, 并且开展了大量端到端的内存泄漏测试。即便这样, 崩溃报告依旧接连不断。
Sumner 写道, 我们的那个 bug 修复列表给人的感觉糟糕透顶, 我厌烦了带着对 Bun 会崩溃的那种担忧去入眠。他并未责怪 Zig , 其他 Zig 用户并未碰到 Bun 这般的问题, 因为把 GC 和手动管理内存混合起来使用, 这本身就是一种极为少见的需求, 基本上没有语言是为此而设计的。
Rust 版本给出的回应是, 同样去实施 2000 次 Bun.build(), 内存稳固于 609MB。
得到根本性解决的, 是内存泄漏问题, 而 Rust 重写不仅带来了内存泄漏问题的根本性解决, 还带来了其他几个维度的改善, 有这样的情况存在。
关于稳定性这一方面, v1.4.0进行了修复, 在v1.3.14里存在着可复现情况的128个bug都被修复了, 其中涵盖从内存泄漏的情况, 到出现崩溃的状况, 再到颜色显示出现错误的帮助文本, 这些均得到了解决。
在体积方面, 经由结合Rust重写, 以及ICU更改, 还有相同的代码折叠, Bun于Linux之上以及Windows之上的二进制文件大小, 减少了大约20%。
关于性能这方面, 普遍有着百分之二至百分之五的提升幅度。Bun.serve从每秒十六点九六万请求的速率提升到每秒十七点七七万请求的速率, node:http从十万三千八百这个数字提升到十万八千五百。在实际应用的场景当中, next build从十三点六二秒下降至十三点零三秒, tsc批量编译从零点九四秒下降至零点八九点。
且 在 Claude Code 依据 Rust Bun 发布之后, 于 Linux 之上的启动时间, 从 517 毫秒降低到了 464 毫秒, 速度加快了大约 10%。
有这样一种方式, 这个方式里包含着64 个 Claude, 历经了11 天的时间, 存在着50 个工作流。
Sumner究竟是怎样达成的, 这兴许是最值得予以关注的那一部分了, 因为他所运用的方式, 与传统的那种“让AI写代码”情形不一样。
Sumner将涵盖整个进程的内容, 拆解成了数量约为50个的、呈现动态特性的工作流, 其中的每一个工作流, 均是一种循环状态, 它在博客里是以伪代码展现的形式对此模式进行论述的表现形式:
有一个上下文属于每个任务, 类似一个Jira ticket或者GitHub issue这样, 基于这个上下文Claude来写出代码, 之后由两个身为Claude的审查者审查那些代码, 紧接着应用得到的反馈, 将这些都完成后，再去拿出下一条任务。
这种模式贯穿了整个重写过程。每个工作流负责一个特定目标：
顶峰阶段, Sumner 同步运转了 4 个工作流程, 每个流程内有 16 个 Claude, 总计 64 个 Claude 一并于 4 个工作树里并行开展工作, 分别进行文件的提交与推送。于最高峰值时, Claude 每分钟撰写了大约 1300 行代码。
关键在于这种“实现者 / 审查者”的分离设计, 写代码的 Claude 期望代码被接受, 这如同人类工程师一样存在偏见, 所以审查者与实现者要完全分开, 审查者只侧重查看代码差异, 而不去关注实现者的推理过程, 并且被明确告知“假设代码是错的”, 每个实现者对应两个以上具有对抗性的审查者, 审查者的唯一工作即为查找 bug。
代码写完仅仅是第一步, Zig代码属于单一编译单元, 然而Rust得拆分成大概100个crate以此加快编译速度, 循环依赖致使cargo check一次性输出差不多16000个编译错误, 对一个人而言这堪称灾难, 不过对64个并行工作的Claude来说, 这是能够处理的工作队列。工作流将错误依据 crate 进行分组, 针对每个 crate 会运行一次 cargo check, 之后由一个 Claude 来进行修复, 接着有两个进行审查的操作, 最后再有一个去应用修改。
紧接着, 要使 bun --version 得以运行起来, 随后便是 bun test。测试工作流每次会随机地去运行 100 个测试文件, 并且会将其分片到 4 个工作树当中。测试套件存在好几种类型: 有一些测试运行的时长会超过一分钟, 有一些测试会使系统 TCP 连接数被耗尽, 有一些测试会 fork 大约 10000 个进程。Sumner 运用 systemd - run 来创建 cgroup 以此限制资源, 然而机器却因为磁盘空间不足而崩溃了好几次。
在两天过后, Linux平台那儿的失败测试数量从总共972个下降到了仅仅23个。可是呢, 在过了一天半以后, Linux平台呈现出了全绿的状态。又过了五天, 涵盖Linux x64、Linux arm64、macOS x64、macOS arm64、Windows x64、Windows arm64这六个全部的平台, 都顺利通过了测试。
5月14日, PR #30412得以正经合并, 测试套件通通过关, 不存在任何被跳过或者被删除的测试。
存在隐忧, 有13,000个不安全的代码, 还存在无法逐行审查的代码。
不过，Sumner 也承认开云真人app官方版入口,开云真人app官网入口，这项工作还没有真正结束。
到目前为止, Bun的Rust代码里大概有4%处在unsafe block内部, 大概有着13,000个unsafe关键字, 散布在大约27,000行代码之中, 而Rust总的代码数量约为780,000行。其中78%的unsafe block仅有一行, 一般是一个源自C++的指针, 或者一回对C库的调用。
有这样一种情况, 他做出预计, 后续进行的重构会使得这个比例下降。然后呢, 存在另一种状况, 有人做了一番计算，得出某种结果, uv大概有着35万行代码, 然而其中unsafe调用仅仅只有73次。还有, 一种数据显示, Bun的unsafe数量达到了uv的178倍。最后, 存在这样一个事实, 这个差距是很难凭借“需要调用C库”来做出解释的。
而且之后在安全的 Rust 代码这儿, 也把未定义行为给暴露出来了。这相比起 C++ 来讲, 调试起来要更困难一些, 毕竟, 你原本会觉得安全代码是不会出现问题的。
之后, Bun团队去做了这样一件事, 将那个问题里的, 也就是PathString::init, 给改成了unsafe fn。
Sumner亲口承认, 此次重写引进了19个业已知晓的回归问题, 还表明多数回归问题源自语法一致然而语义各异的代码。
举例来说, 这两个代码片段看上去极为相像, 然而其行为表现却有着天壤之别。Zig的代码里, assert属于一个函数, 所以它的参数在每次进行构建之时都会去运行。Rust的代码当中, debug_assert!属于一个宏, 因而在发布版本中, 整个表达式（涵盖函数调用）都会被删除insert_stale。
尽管已然那些问题都给修复了, 然而这并不能表明百万行的AI代码就不存在别的问题。
正常的人当中又有谁会在那种运行的时候被完全彻底地重新编写之后, 马上就把自身的生产应用迁移过去呢? 要是觉得1.4版本没有引进新的漏洞, 或者没有产生行为方面的改变, 那就实在是太幼稚天真了。
还要注意的是, 代码审查这件事不能被忽视。100万行的变更, 人类没办法逐行去看, 哪怕一分钟看一行, 那也需要连续看上11.7天。按照实际的代码审查速度, 也就是一小时看200行, 那得两年多才能看完。
主要对这次PR进行审查的是claude以及coderabbitai, Sumner自己也承认, 他所采用的审查方式为, 检查对抗性审查agent是不是正确捕获到了差异, 要确保转换指南是被遵守的, 与此同时, 他自己也手动阅读了数量不少的代码, 然而, 他并没有说明, 所谓的“不少”究竟是多少。
还存在一个无法回避的问题, Bun于2025年12月被Anthropic收购了, 真正能够切实有效维护这套代码库的工具, 基本上唯有Claude自身。社区当中有人讲, 这已然不能算作传统意义层面的开源项目了, 你若想要给Bun提交PR, 就得先进行Anthropic的订阅, 又或者寄希望于那几个已然理解了AI生成代码的核心成员。
16.5 万美元换一年工作量开云app官方最新下载地址，值吗？
Sumner于博客里还透露, 此次被重写的API成本达约16.5万美元, 这等同于3名工程师一整年的工作量, 此数字在Hacker News上引发了极为热烈的讨论。
有人觉得, 这笔账确实是挺划算的。在硅谷, 16.5万美元根本雇用不来几个全职方面的专业工程师, 更何况像Anthropic这类有着特定级别划分的公司的工程师呢, 按照levels.fyi网站上所呈现出来的薪资具体数据, Anthropic公司工程师的总包很有可能会达到50万美元甚至还要更高一些。就算是以50名分处于工程师岗位的人员平均每年薪资为33.6万美元开展粗略的计算, 折合下来每一天大约是1292美元。有五十个人, 连续工作了十一天, 仅仅是人力成本, 就已经快要接近七十一万美元了。并且, 这还不涵盖福利、办公场地、设备以及其他管理开销呢。
然而, Sumner所采用的乃是“Claude Fable 5的预发布版本”, 这是一个未曾面向公众开放、极有可能遭受出口管制的高阶模型。故而API定价仅仅是最终用户所目睹的数字, 其背后暗藏着Anthropic投入的数额巨大的研发费用。另外有人表明, 将成本简化为API定价, 乃是在蓄意淡化实际投入。要是把模型研发成本、训练成本、算力投入、工程人力等一并算入, 想必最终的总成本必定很高, 极有可能超出150万美元。
并且就当前情形而言, 尽管是以十六点五万美元去换取一整年的工作量, 从账目表象来看是颇为划算的。
但真正的成本并不在这张账单之上, 这个代码库存在着6778次提交, 而且没有任何一个人能够从开头到结尾完整地阅读过, 尽管当下所有情况都处于正常状态, 可是六个月之后又会怎样呢? 当某个极为诡异的并发问题在凌晨三点突然毫无预兆地冒出来时, 负责值班的工程师所面对的是一个就连他自己都无法清晰说清其内部逻辑的系统, 从这延伸到往后都需要依靠AI来进行维护, 那么维护成本究竟该如何计算, 实际上是相当困难的。
参考链接：
通过这个链接, https://bun.com/blog/bun-in-rust , 可查看相关内容。
https://hn.edgecompute.app/item/48837877
标签： AI 代码迁移 Rust Bun项目 ClaudeCode
还木有评论哦，快来抢沙发吧~