Bun Rust重写：16.5万美元的AI谎言？

我不确定从这里的提交数量和发布节奏中能看出多少门道。在经历如此重大的重构/重写之后，我预期他们需要一些时间才能恢复到往常的开发速度。

Jared 和其他开发者对 Rust 代码库来说都是新人，即使整体结构大同小异。他们目前可能也正专注于其他优先事项，比如排查 'unsafe' 代码的使用实例，而不是做面向用户的改动（后者可能会促使他们发布新版本）。

Bug 修复可能会推动快速发布新版本，但也许这次重写本身并没有那么多 Bug？据我所知，canary 频道的用户并没有报告任何重大问题，甚至都没怎么注意到这个变化。所以，也许团队目前确实没有太多理由发布新版本，他们正在慢慢处理积压的任务。

> P.S. Anthropic 的 C 编译器和 Cursor 的 FastRender 浏览器已经几个月没有提交了。

我一直以为那些只是能力验证的实验，并非打算长期维护的项目。我希望现在没人会直接使用它们。

我确实相信他们当时试图使用 CodeRabbit 来审查他们重写的代码。

https://www.coderabbit.ai/blog/ai-can-migrate-your-entire-co...

我真的完全不懂现在的软件开发者是怎么想的。利用 LLM 在短时间内将一个项目移植过去，这本身就不可思议。就像一键生成各种 Office 克隆体一样。

但软件的核心不在于快速制造出一个“产品”，而在于实际的功能开发。搞清楚所有东西如何协同工作，修复 Bug，以及那些极其枯燥的 UI 工作。

我曾经为了好玩，用 LLM 做过类似 Word 的克隆体。结果是一场灾难。当然，它具备基本功能。但一旦你开始处理页面结构（比那种单页无限滚动的页面难得多）、表格、图片、旋转，以及构成 Word 基础功能的无数细节时——甚至连扩展功能都没涉及——你就会看到每个 LLM 都当场翻车。

当然，我可以把 sqlite 从 C 克隆到 Rust。天哪，我甚至可能让它通过 100% 的测试。但有 99% 的几率，这个克隆版会更慢，因为它缺乏原语言多年积累的性能优化。语言切换也会带来新 Bug。未来还需要支持和修复。

人们把软件当成了它不是的东西。但不同于过去，当你向客户收取 10 万美元软件费时，他们会质疑你的理智，因为他们不理解这不仅仅是写代码。现在，由于这类文章的存在，这种期望被推得更远了。

我常在 Reddit 上看到有人发布能实现 X、Y、Z 功能的软件，结果作者抛弃它的速度比他们 […]

作为一个对比，有人决定尝试修复 Zig 原版中的问题，并声称通过现代化代码库和遵循最佳实践，实现了亚秒级的构建时间并修复了 Bug。这表明所有当初证明重写合理的问题，其实都是自找的，且完全可以解决。

https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...

我在这个游戏中没有利益瓜葛，而且 Zig 版本也使用了 LLM，如果这有助于消除“文化战争”的意味的话。但根据我的经验，一直如此：真正理解问题领域的人，总是能胜过那些只是投入资源（花费数十万美元的 token）去硬砸的人。

Bun 的重写激励我在移植代码、重写代码或将外部依赖引入内部（vendor）时变得更加激进，以便以不符合上游利益的方式，专门针对我们的需求进行定制。

我觉得这让我在把什么任务扔给代码模型时变得更加雄心勃勃，但也让我更加专注于我们的测试框架，并将大量测试保留在语言无关的边界之外。

作为参与过几次大型重写（有些长达数年）的一员，我绝对认为 Bun 的重写是一个巨大的成功。在保持如此高水平的测试和功能对等性的同时，还能在此基础上增加改进，这是一项巨大的工程壮举。

我确实怀疑那些凯旋式的宣言，甚至那个看似诚实直率的深度分析，都稍微有点过早了。

这是 LLM 狂热带来的一个关键问题：利用 LLM 来变现几十年的软件经验非常诱人，因为你厌倦了打字和手动摸索，只要你有能力，它似乎就能奏效，而且回报几乎是立竿见影的。但真正的账单要很久以后才会寄到。

我认为，我们大家的表述都错了。Bun 是由 AI 用 Rust 重写的，但仅确保了集成测试和使用测试通过。这类似于将 C 程序编译为二进制，或将 TypeScript 转译为 JavaScript 并运行。当时我们并没有对此大惊小怪，我认为我们应该将这次操作视为一种类似的、更高层级的源到源翻译，而机器一直在做这种事。

写代码是另一回事。