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

# Bun 的问题可能在于公开开发 来源：https://00f.net/2026/05/17/developping-in-the-open/ 当人们发现 Bun 的一个分支提到尝试用 LLM 将现有的 Zig 代码移植到 Rust 时，他们炸了。 那是一个个人实验，在一个非默认的 Git 分支上，没有在任何地方公布。 但这并不重要。Rust 拥护者们开香槟庆祝。Zig 社区震惊了。真正的 Bun 用户感到困惑。所有人都在幼儿园操场上像小孩一样争吵。 Jarred Sumner 在 Bun 上遇到了一些问题。也许根本原因是最初的技术决策，而不是 Zig 本身的固有特性。也许迁移到另一种语言能解决其中一些问题。也许不能。但尝试一下并不可怕。 重写软件通常是重新审视代码如何工作、消除技术债务、产出更好成果的好方法。尤其是当产品的成熟形态已经明确时。你无需重新发现每一个边界情况、每一个别扭的特性、每一个因为最初设计没有预料到现实而添加的 hack。 重写 Bun 仍然是一项艰巨的任务。 但尽管所有人都在谈论 Bun 的重写，这其实并不是真正的计划。 计划更像是这样的： 1. 将 Zig 代码转译到 Rust。每个文件、函数和结构都应尽可能保持与原始代码接近，使得 Zig 文件和对应的 Rust 文件在功能上可以互换。 2. 逐步调整、重写和重构单个函数和类型，直到代码变成地道、可维护的 Rust。 3. 最终，得到一个 Rust 重写版本。 Bun 只完成了第一阶段。 这是转译后的代码。自动转译的代码。由于没有 Zig 到 Rust 的转译器，Jarred 使用了 AI 提示。 而且它成功了。 成功是指：测试通过了。 这并不十分令人惊讶。LLM 擅长翻译文本，而代码是具有大量结构的文本。如果你给它们一个庞大的测试套件以防止它们偏离轨道，这种机械翻译正是它们能做好的事情。 Anthropic 可以用它来展示 Claude，但大多数编码模型在给定正确指令的情况下可能也能完成类似的工作。 生成的 Rust 代码质量很差。 当然很差。 一位有经验的 Rust 开发者不会在自己的项目中接受这样的代码。显然，它被嘲笑了，包括那些最初为 Bun “重写”为 Rust 而欢呼的 Rust 拥护者。 但地道 Rust 在当时并不是目标。 第一阶段的目的是对 Zig 代码进行字面、直接的翻译。在这种背景下，Rust 几乎就是一种中间表示。事实来源仍然是 Zig。Rust 输出是为了看看在任何人开始改进结果之前，翻译流水线能否保持行为一致。 第一阶段的目的不是生成漂亮的 Rust。 而是回答一个狭窄的问题：一个大型 Zig 代码库能否被自动翻译，并且保真度足够高，使得测试套件通过？ 显然，可以。 借助 AI，这是一个容易运行的实验。它很快。如果你不支付 token 费用，它还很便宜。失败是可以接受的，因为它不需要太多投入。这正是 Jarred 将其描述为实验的原因。 然而，从外部来看，故事看起来非常不同。 人们看到了一个泄露的意图，要做一些有争议的事情。然后他们看到有争议的事情变成了现实。然后他们看到了可怕、丑陋的生成 Rust代码。短短几天内，Bun 从人们信任并在生产环境中使用的工具，在他们心目中变成了一把被 AI 盲目重写、几乎没有任何质量控制的工具。 于是他们恐慌了。 这里有不舒服的部分：这场风波的根源可能在于 Jarred 行事透明。 他本可以将 Rust 分支保持私有，直到第三阶段完成。如果实验失败，他完全可以不提。 然后，很久以后，他可以宣布一个新的 Bun 版本，实际上用 Rust 重写了，代码所有人都认可，稳定性也优于原始实现。 语言拥护者仍然会争吵。当然。但真正的用户多半会根据结果来判断。 它能用吗？可靠吗？新版本比之前的更好吗？ 如果是，很好。如果不是，那就有充分理由离开。 大多数用户并不真正关心软件是如何构建的。他们关心他们依赖的工具是否继续工作。 但 Jarred 没有做安全的公司式操作。他公开工作，包括实验最早、最丑陋的部分。 结果适得其反。 不幸的是，这是一个常见的开源问题。 维护者需要做实验。这是项目工作中的正常部分。在探索想法时，写出未完成、丑陋、不安全、半残的代码是完全可以的。将这些分支推送到 GitHub 也很方便。 是的，存在替代方案。但如果你在多台设备上工作，或者想与一个人共享分支，将其推送到与其他所有内容相同的远程仓库是迄今为止最简单的工作流。任何其他方式都会增加摩擦。 问题是，推送至公共仓库的每一点内容都可能成为被解读的材料。 人们会看它。他们会评判它。他们会为它赋予意图。他们会自己编写缺失的上下文，通常以最不体谅的方式。 如果一个项目是开源的，维护者不知为何被期望让每一个公开提交看起来干净、连贯、且具有战略上的终极性。 这很荒谬。 这也会改变行为。项目越流行，维护者公开思考的自由就越少。一个随机的分支不再是草稿纸，而变成了新闻稿。一个快速实验变成了路线图。一个糟糕的中间结果变成了项目失去理智的证据。 于是维护者学会了显而易见的教训：隐藏混乱的部分。 这对所有人都不利。 对 Bun 的教训并不是 AI 重写是好的。也不是 Rust 会修复 Bun。也不是 Zig 是问题所在。这些都没有被这个实验证明。 教训是：公开开发和公开实验不是一回事。 用户想要透明度，但他们也惩罚未完成的工作。维护者想要开放性，但他们也需要私人空间来尝试愚蠢的想法，然后再决定它们是否真的愚蠢。 对于大型项目，也许实际的答案很无聊：将实验保持私有，直到它们拥有足够的上下文供人理解，或者给它们加上极其醒目的标签，使没有人能假装它们是生产计划。 这不如在开放中开发一切那么浪漫。 但如果每一个丑陋的分支都演变成风波，更多的维护者将停止展示丑陋的分支。 然后大家又会抱怨开源变得不那么开放了。