Bun’s problem may be developing in the open

Bun 的问题可能在于“公开开发”

As soon as people found a Bun branch mentioning an experiment to use an LLM to port the existing Zig code to Rust, they went mad. It was a personal experiment, on a non-default Git branch, not announced anywhere. That didn’t matter. Rust advocates popped champagne. Zig people were shocked. Actual Bun users got confused. Everybody fought like kids in a kindergarten playground. 当人们发现 Bun 的一个分支提到了一项使用大语言模型（LLM）将现有 Zig 代码移植到 Rust 的实验时，他们彻底疯狂了。这只是一个个人实验，位于一个非默认的 Git 分支上，且未在任何地方公开。但这并不重要。Rust 的拥护者们欢呼雀跃，Zig 的支持者们感到震惊，而真正的 Bun 用户则感到困惑。所有人像幼儿园操场上的孩子一样吵作一团。

Jarred Sumner has issues with Bun. Maybe the root cause is original technical decisions rather than anything inherent to Zig. Maybe moving to another language could help with some of them. Maybe not. But trying is not insane. Rewriting software is often a good way to revisit how the code works, remove technical debt, and produce something better. Especially when the mature shape of the product is already known. You don’t have to rediscover every edge case, every awkward feature, and every hack that got added because the original design didn’t anticipate reality. Jarred Sumner 对 Bun 确实存在一些顾虑。也许根本原因在于最初的技术决策，而非 Zig 语言本身的问题。换一种语言或许能解决其中一些问题，或许不能。但尝试本身并不疯狂。重写软件通常是重新审视代码运行机制、消除技术债务并产出更优方案的好方法。特别是在产品形态已经成熟的情况下，你无需重新探索每一个边缘情况、每一个尴尬的功能，以及那些因为原始设计未预见现实而添加的各种“补丁”。

Rewriting Bun would still be a significant task. But despite everybody talking about a Bun rewrite, that was not really the plan. The plan looked more like this: Transpile the Zig code to Rust. Every file, function, and structure should remain as close as possible to the original, so that a Zig file and its Rust equivalent are functionally interchangeable. Incrementally tweak, rewrite, and refactor individual functions and types until the code becomes idiomatic, maintainable Rust. Eventually, get a Rust rewrite. 重写 Bun 仍然是一项艰巨的任务。但尽管大家都在谈论 Bun 的重写，这其实并非最初的计划。计划更像是这样：将 Zig 代码转译为 Rust。每一个文件、函数和结构都应尽可能保持与原版一致，以便 Zig 文件及其对应的 Rust 代码在功能上可以互换。通过逐步调整、重写和重构单个函数与类型，直到代码变成地道且易于维护的 Rust 代码。最终，实现 Rust 版本的重写。

Bun completed phase 1 only. This is transpiled code. Automatically transpiled code. Since there are no Zig-to-Rust transpilers, Jarred used an AI prompt. And it worked. As in: the tests passed. And that is not very surprising. LLMs are good at translating text, and code is text with a lot of structure. If you give them a large test suite to keep them from going off the rails, this kind of mechanical translation is exactly the sort of thing they can do well. Anthropic can use it to show off Claude, but most coding models could probably do something similar with the right instructions. Bun 目前仅完成了第一阶段。这是转译代码，而且是自动转译的代码。由于目前没有现成的 Zig 转 Rust 转译器，Jarred 使用了 AI 提示词。结果成功了，测试通过了。这并不令人惊讶。大语言模型擅长翻译文本，而代码就是一种结构严谨的文本。如果你提供一个庞大的测试套件来防止它们“跑偏”，这种机械式的翻译正是它们擅长的工作。Anthropic 可以用它来展示 Claude 的能力，但大多数编程模型在正确的指令下大概都能做到类似的事情。

The resulting Rust code was of poor quality. Of course it was. An experienced Rust developer would not accept code like that in their own project. And obviously, it was mocked, including by Rust advocates who had originally rejoiced at the idea of Bun being “rewritten” in Rust. But idiomatic Rust was not the goal at that point. Phase 1 was meant to be a literal, direct translation of the Zig code. In that context, Rust is almost an intermediate representation. The source of truth is still Zig. The Rust output is there to see whether the translation pipeline can preserve behavior before anyone starts improving the result. 生成的 Rust 代码质量很差。这当然是意料之中的。经验丰富的 Rust 开发者绝不会在自己的项目中接受这样的代码。显而易见，它遭到了嘲笑，包括那些最初为 Bun 将被“用 Rust 重写”而欢呼的 Rust 拥护者们。但在那个阶段，地道的 Rust 代码并非目标。第一阶段旨在对 Zig 代码进行字面意义上的直接翻译。在这种语境下，Rust 几乎充当了一种中间表示层。事实来源依然是 Zig。Rust 输出的存在是为了验证翻译流水线能否在任何人开始优化结果之前保持行为的一致性。

Phase 1 was not about producing beautiful Rust. It was about answering a narrow question: can a large Zig code base be translated automatically, with enough fidelity for the test suite to pass? Apparently, yes. With AI, that is a simple experiment to run. It is quick. It is cheap when you don’t pay for tokens. Failure is acceptable because it doesn’t require much commitment. That is exactly why Jarred described it as an experiment. 第一阶段的目的不是产出优美的 Rust 代码，而是回答一个狭窄的问题：一个庞大的 Zig 代码库能否被自动翻译，且保真度足以让测试套件通过？显然，答案是肯定的。有了 AI，这是一个简单的实验。它很快，而且在不考虑 Token 成本时非常廉价。失败是可以接受的，因为它不需要太多的投入。这正是 Jarred 将其描述为“实验”的原因。

From the outside, though, the story looked very different. People saw a leaked intention to do something controversial. Then they saw the controversial thing materialize. Then they saw horrific-looking generated Rust. In a few days, Bun went from a tool people trusted and used in production to, in their minds, a tool being blindly rewritten by AI with minimal quality control. So they panicked. 然而，从外部视角看，故事完全变了样。人们看到了一个关于进行争议性操作的“泄露”意图，接着看到了争议性操作的实现，然后看到了看起来极其糟糕的生成式 Rust 代码。短短几天内，Bun 在人们心目中的形象从一个值得信赖的生产级工具，变成了一个被 AI 盲目重写且缺乏质量控制的工具。于是，他们恐慌了。

Here is the uncomfortable part: the root cause of the drama may be that Jarred acted transparently. He could have kept the Rust branch private until phase 3 was complete. And if the experiment failed, he could have never mentioned it. Then, much later, he could have announced a new Bun version, actually rewritten in Rust, with code everyone agreed was good and stability numbers better than the original implementation. Language advocates would still have fought. Of course. But actual users would mostly have judged the result. Does it work? Is it reliable? Is the new version better than the previous one? If yes, cool. If no, that is a good reason to leave. Most users do not really care how software is built. They care whether the tool they rely on keeps working. 令人不安的部分在于：这场闹剧的根本原因可能恰恰是 Jarred 太过透明了。他本可以将 Rust 分支保密，直到第三阶段完成。如果实验失败，他完全可以只字不提。然后，在很久之后，他可以宣布一个全新的 Bun 版本，一个真正用 Rust 重写、代码质量得到公认且稳定性优于原版的产品。语言拥护者们当然还是会争吵，但真正的用户大多只会根据结果来评判：它好用吗？可靠吗？新版本比旧版本更好吗？如果是，那很好；如果不是，那也是离开的充分理由。大多数用户并不关心软件是如何构建的，他们只关心自己依赖的工具是否能持续正常工作。

But Jarred did not do the safe corporate thing. He worked in the open, including the earliest and ugliest part of the experiment. And that backfired. Unfortunately, this is a common open source problem. Maintainers need to experiment. That is a normal part of working on a project. It is fine to write unfinished, ugly, unsafe, half-broken code while exploring an idea. It is also convenient to push these branches to GitHub. Yes, alternatives exist. But if you work from multiple devices, or want to share the branch with one person, pushing it to the same remote as everything else is by far the easiest workflow. Anything else adds friction. 但 Jarred 没有选择那种稳妥的“企业式”做法。他在公开环境下工作，包括实验中最早期、最丑陋的阶段。这导致了反噬。不幸的是，这是一个常见的开源问题。维护者需要实验，这是项目开发中正常的一部分。在探索想法时，写出未完成、丑陋、不安全、半残的代码是没问题的。将这些分支推送到 GitHub 也很方便。是的，确实有其他替代方案，但如果你在多台设备上工作，或者想与某人共享分支，将其推送到与其他代码相同的远程仓库无疑是最简单的工作流。任何其他方式都会增加阻力。

The problem is that every bit pushed to a public repository becomes material for interpretation. People will look at it. They will judge it. They will assign intent to it. They will write the missing context themselves, usually in the least charitable way possible. If a project is open source, maintainers are somehow expected to make every public commit look clean, coherent, and strategically final. That is absurd. It also changes behavior. The more popular a project becomes, the less freedom maintainers have to think in public. A random branch stops being a scratchpad and becomes a press release. A quick experiment becomes a roadmap. A bad intermediate result becomes proof that the project has lost its mind. So maintainers learn the obvious lesson: hide the messy parts. That is bad for everyone. 问题在于，推送到公共仓库的每一比特代码都成了被解读的素材。人们会审视它、评判它、赋予它某种意图。他们会自行脑补缺失的背景信息，通常是以最不友善的方式。如果一个项目是开源的，维护者似乎就被要求让每一个公开提交看起来都整洁、连贯且具有战略定论。这很荒谬，也改变了行为模式。一个项目越受欢迎，维护者在公开场合思考的自由就越少。一个随意的分支不再是草稿，而变成了新闻稿；一个快速的实验变成了路线图；一个糟糕的中间结果变成了项目“疯了”的证据。于是，维护者们学到了一个显而易见的教训：隐藏那些混乱的部分。这对所有人来说都是一种损失。

The lesson for Bun is not that AI rewrites are good. It is not that Rust would fix Bun. It is not that Zig is the problem. None of that is proven by this experiment. The lesson is that public development and public experimentation are not the same thing. 对于 Bun 而言，教训不是“AI 重写很好”，不是“Rust 能修复 Bun”，也不是“Zig 是问题所在”。这些都没有被这个实验所证明。真正的教训是：公开开发与公开实验并不是一回事。