Bun 1.4 Rust rewrite is not looking good

Bun 1.4 的 Rust 重构前景堪忧

I care about Bun. I have been rooting for it since the initial release in 2022. I switched all my development from Node to Bun. I used it in the development of the Nue framework and now with my new project Hertta. The last three months have not looked good for Bun. It started as one of the most impressive individual engineering projects I have seen, but has now turned into this weird AI-powered creature with continuous false promises and an increasingly frustrated community.

我非常关心 Bun。自 2022 年首次发布以来，我一直支持它。我将所有的开发工作从 Node 迁移到了 Bun。我曾用它开发 Nue 框架，现在又用它开发我的新项目 Hertta。但过去三个月，Bun 的表现并不理想。它最初是我见过最令人印象深刻的个人工程项目之一，但现在却变成了一个奇怪的、由 AI 驱动的产物，伴随着不断的虚假承诺和日益沮丧的社区。

In the next version of Bun used to be a positive tweet to watch for. For years it meant a feature had been implemented, tested, and would ship in a few days. This changed after the Rust rewrite. Now the posts are false promises about the upcoming release:

“In the next version of Bun”（在下一个 Bun 版本中）曾经是一条值得期待的正面推文。多年来，这意味着某个功能已经实现、测试完毕，并将在几天内发布。但在 Rust 重构之后，情况变了。现在的推文变成了关于即将发布版本的虚假承诺：

Jun 24: Bun v1.4 ships July 7th. (6月24日：Bun v1.4 将于 7 月 7 日发布。)
Jul 4: Bun v1.4 hopefully Tuesday (7月4日：Bun v1.4 希望在周二发布)
Jul 7: (The date passes) (7月7日：日期已过)
Jul 14: In the next version of Bun (7月14日：在下一个 Bun 版本中)
Jul 20: In the next version of Bun (7月20日：在下一个 Bun 版本中)
Jul 29: Bun v1.4 fixes over 3000 issues over v1.3 (7月29日：Bun v1.4 修复了 v1.3 的 3000 多个问题)
Aug 1: In the next version of Bun (8月1日：在下一个 Bun 版本中)
Aug 4: In the next version of Bun (8月4日：在下一个 Bun 版本中)
Aug 7: 1 more PR to merge then it’ll be time for Bun v1.4 (8月7日：再合并一个 PR，Bun v1.4 就可以发布了)
Aug 13: Bun v1.4 is compiling. (8月13日：Bun v1.4 正在编译中。)
Aug 15: Bun v1.4 is delayed until Monday (8月15日：Bun v1.4 推迟到周一)
Aug 17: Let’s say tomorrow (8月17日：就说是明天吧)

It’s now three months and counting since the last stable release, the longest gap in Bun’s history since 2022. Nothing unusual there. Software slips, that’s normal. It’s just that an account which used to communicate with real dates and real numbers has switched to vibing. And the user reaction is what you’d expect after constant false promises:

距离上一个稳定版本发布已经过去了三个多月，这是 Bun 自 2022 年以来最长的空窗期。这本身没什么大不了的，软件延期很正常。问题在于，一个曾经用真实日期和数据进行沟通的账号，现在却开始“凭感觉”行事。用户在面对不断的虚假承诺后，反应也是意料之中的：

@jarredsumner okay I’m editing blog post it’s mostly done if I say a date you won’t believe me but let’s say tomorrow We totally believe in you, Jarred Rejoice fellas, tomorrow in Jarred Standard Time zone means we have a new blog coming next week. You won’t care, but personally I am switching to go now. It’s not even funny, you are just stringing your users along again and again. How can we believe you? You always make promises that you can’t keep, tomorrow, next week, Monday… If you need 2 months to release it you can just say that instead of saying you’ll ‘release it tomorrow’ every week

@jarredsumner 好的，我正在编辑博客文章，基本完成了。如果我说个日期你肯定不信，但就说是明天吧。我们完全相信你，Jarred。兄弟们欢呼吧，Jarred 标准时区的“明天”意味着我们下周会有新博客看。你可能不在乎，但我个人现在要转去用 Go 了。这根本不好笑，你只是在一次又一次地吊着你的用户。我们怎么能相信你？你总是做出无法兑现的承诺：明天、下周、周一……如果你需要 2 个月才能发布，你可以直接说，而不是每周都说“明天发布”。

Bun on GitHub

GitHub 上的 Bun

The Bun 1.4 rewrite is a big bet on AI. In the past month, 15.8k commits came from robobun, 1.6k commits from autofix-ci[bot], and 790 commits from Jarred. 6 months ago, most of Bun’s PRs came from people prompting Claude. Nowadays, most of Bun’s PRs come from Claude prompting Claude. The project has over 5k open pull requests, which is the largest number of pull requests I’ve seen. For comparison, OpenClaw has 2.2k, and React has 441. GitHub recommends staying under 1,000 open PRs against a single branch before mergeability checks start timing out.

Bun 1.4 的重构是对 AI 的一场豪赌。过去一个月里，15,800 次提交来自 robobun，1,600 次来自 autofix-ci[bot]，790 次来自 Jarred。6 个月前，Bun 的大部分 PR 来自人类向 Claude 发送提示词；而现在，大部分 PR 来自 Claude 向 Claude 发送提示词。该项目有超过 5,000 个未处理的 Pull Request，这是我见过最多的。作为对比，OpenClaw 有 2,200 个，React 有 441 个。GitHub 建议单个分支的未处理 PR 保持在 1,000 个以下，否则合并检查可能会超时。

The biggest worry is, of course, the code itself. In the early days Jarred’s work was inspirational. I thought he was a true Zig talent, until I read Zig creator Andrew Kelley’s thoughts on the Bun rewrite: “We became increasingly horrified at the programming practices we saw in Bun’s codebase. Hacks on top of hacks. Abuse of assertions.” Jarred was already writing slop well before he had access to LLMs. What was the problem with Zig?

最令人担忧的当然是代码本身。早期 Jarred 的工作非常鼓舞人心。我曾认为他是真正的 Zig 天才，直到我读到了 Zig 创建者 Andrew Kelley 对 Bun 重构的看法：“我们对 Bun 代码库中的编程实践感到越来越恐惧。各种补丁堆叠，滥用断言。” Jarred 在接触 LLM 之前就已经在写烂代码了。Zig 到底有什么问题？

This rewrite is the most closely watched real-world test of whether AI agents can take over a production codebase with a human mostly directing rather than reading. Anthropic’s own reputation is also on the line: if this goes well, it is real proof of what agentic coding can do. If it goes badly, it will send a signal in the opposite direction. The number of unsafe blocks in the Rust code suggests the rewrite did not deliver the memory safety that was given as the reason for doing the rewrite in the first place. Instead this rewrite feels more like an Anthropic ad.

这次重构是 AI Agent 能否在人类主要负责指导而非阅读代码的情况下接管生产级代码库的最受关注的现实测试。Anthropic 自身的声誉也岌岌可危：如果成功，这将是 AI 智能体编程能力的有力证明；如果失败，则会释放出相反的信号。Rust 代码中大量的 unsafe 代码块表明，这次重构并没有实现当初作为重构理由的“内存安全”。相反，这次重构感觉更像是一则 Anthropic 的广告。

And was Zig really the problem? Bun’s early identity was built on Zig: its performance, its fast compile times, its low friction, its direct memory control with a small team. It feels like Jarred and Anthropic decided early on that this was going to be written in Rust, and used Zig’s memory issues as the excuse to let the world know how powerful Claude is. A rewrite like this would make great headlines, and it certainly did. Now we’re looking at the long tail of issues from the rewrite they didn’t prepare for. Maybe Bun should have put that same AI-assisted effort into disciplined, human-understood Zig instead of a full language change. I never saw Jarred seriously engage with this option. And ‘tomorrow’ has come and gone. Still no v1.4. ¯_(ツ)_/¯

Zig 真的是问题所在吗？Bun 早期的身份是建立在 Zig 之上的：它的性能、快速的编译时间、低摩擦力，以及小团队对内存的直接控制。感觉 Jarred 和 Anthropic 很早就决定要用 Rust 重写，并以 Zig 的内存问题为借口，向世界展示 Claude 有多强大。这样的重构确实能制造巨大的新闻头条，他们也确实做到了。现在，我们看到的是重构带来的、他们未曾预料到的长尾问题。也许 Bun 本可以将同样的 AI 辅助精力投入到规范的、人类可理解的 Zig 代码中，而不是进行彻底的语言更换。我从未见过 Jarred 认真考虑过这个选项。而“明天”已经过去。依然没有 v1.4。¯_(ツ)_/¯