我关心 Bun。自 2022 年首次发布以来，我一直在支持它。我已经将所有开发从 Node 切换到 Bun。我在 Nue 框架的开发中使用它，现在在我的新项目 Hertta 中也在使用。过去三个月的情况对 Bun 来说并不好。它起初是我所见过的最令人印象深刻的独立工程项目之一，但现在却变成了这个奇怪的 AI 驱动的生物，伴随着不断的虚假承诺和越来越沮丧的社区。在 Bun 的下一个版本中，以前是值得期待的积极推文。多年来，这意味着某个功能已经实现、测试，并将在几天内发布。在 Rust 重写之后，这种情况发生了变化。现在发布的帖子是关于即将发布的虚假承诺：自从上一个稳定版本以来，已经过去了三个月，这也是自 2022 年以来 Bun 历史上最长的间隔。没什么 unusual 的。软件延期是正常的。只是曾经用真实日期和真实数字与用户沟通的账户，现在切换到了模糊不清的表述。而用户的反应正如你所预期的那样：@jarredsumner，好吧，我正在编辑博客帖子，基本上快完成了，如果我说一个日期你不会相信我，但我们就说明天吧。我们完全相信你，Jarred。大家欢呼吧，明天在 Jarred 标准时区意味着我们下周将有新的博客发布。你可能不在意，但就我个人而言，我正在转向 Go。根本没什么好笑的，你只是在一遍又一遍地拖延用户。我们怎么能相信你？你总是做出无法兑现的承诺，明天、下周、星期一……如果你需要两个月来发布它，你可以直接说，而不是每周说你会“明天发布”。在 GitHub 上的 Bun。Bun 1.4 的重写是对 AI 的一次重大投资。在过去一个月中，来自 robobun 的提交有 15800 个，来自 autofix-ci[bot] 的提交有 1600 个，来自 Jarred 的提交有 790 个。六个月前，大多数 Bun 的 PR 是由人们给 Claude 提交的。如今，大多数 Bun 的 PR 是由 Claude 自己提交的。该项目有超过 5000 个未处理的拉取请求，这是我见过的最多的拉取请求。相比之下，OpenClaw 有 2200 个，React 有 441 个。GitHub 建议在与单个分支的合并检查开始超时之前，保持未处理的 PR 数量在 1000 以下。最大的担忧当然是代码本身。在早期，Jarred 的工作令人鼓舞。我曾认为他是真正的 Zig 人才，直到我阅读了 Zig 创建者 Andrew Kelley 对 Bun 重写的看法：我们对 Bun 的代码库中观察到的编程实践感到越来越恐惧。层层叠加的黑客。对断言的滥用。在获得 LLM 访问权限之前，Jarred 已经在写烂东西。Zig 的问题是什么？这次重写是对 AI 代理能否接管一个生产代码库的最密切关注的现实测试，主要是由人类指导而不是阅读。Anthropic 自身的声誉也悬于一线：如果这次成功，那将是真正证明代理编程可以做到什么的证据。如果它不成功，这将向相反的方向发出信号。Rust 代码中不安全块的数量表明，这次重写没有提供最初进行重写所给出的内存安全。相反，这个重写更像是一次 Anthropic 的广告。那么 Zig 真的是问题吗？Bun 的早期身份是建立在 Zig 的基础上的：它的性能、快速的编译时间、低摩擦和小团队的直接内存控制。感觉 Jarred 和 Anthropic 很早就决定要用 Rust 来编写这个项目，并利用 Zig 的内存问题作为借口，让世界知道 Claude 是多么强大。这样的重写将会成为一个伟大的头条新闻，而且确实如此。现在我们正面临重写后没有准备好的各种问题。或许 Bun 应该将那种 AI 辅助的努力投入到有纪律、易于理解的 Zig 中，而不是完全的语言改变。我从未看到 Jarred 认真考虑过这个选项。而“明天”已经来来去去了。仍然没有 v1.4。¯\_(ツ)_/¯