Bun 对 Rust 的重写是一项了不起的成就
MMaximilian Schwarzmüller
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00BUN 已从 SIG 移植到 Rust。
00:00:02你可能已经听说过这件事了，
00:00:04但其中有很多值得深入探讨的内容。
00:00:06上周出现了很多争议，
00:00:08但也发生了很多有趣的事情。
00:00:10无论你对 BUN、SIG 还是 Rust 是否感兴趣，
00:00:14这都非常引人入胜。
00:00:15这也涉及到如何利用人工智能，
00:00:18以及这对我们行业内类似项目
00:00:20对我们整个行业意味着什么。
00:00:22顺便提一下，
00:00:24我个人非常喜欢 BUN。
00:00:26它是我在大多数项目中默认使用的 JavaScript 运行时。
00:00:29而且，很巧的是，
00:00:30我上周刚刚发布了一门关于 BUN 的新课程。
00:00:32当然，它既适用于 Rust 版本，也适用于 SIG 版本。
00:00:35所以如果你想深入了解 BUN，
00:00:37并学习它所提供的所有核心 API，
00:00:39因为这是 BUN 最大的优势之一，
00:00:41即它内置了丰富的功能。
00:00:44有些人不喜欢这样，但我很喜欢。
00:00:46如果你想了解更多相关信息，
00:00:48那门课程可能对你有帮助。
00:00:50现在，让我们仔细看看
00:00:51整个移植的时间线，好吗？
00:00:53它实际上发生在两个月前。
00:00:54博文虽然是在七月上旬发布的，
00:00:58但移植本身是在五月完成的。
00:01:01它始于五月初，当时在官方 BUN GitHub 仓库中
00:01:04发现了 CloudFaserPort 分支。
00:01:08该分支包含了一个 porting.md 文件，
00:01:10即一份包含如何将 SIG 代码转换为 Rust 代码说明的 Markdown 文件，
00:01:13在官方的 BUN GitHub 仓库上。
00:01:15那个分支包含了一个移植说明 Markdown 文件，
00:01:18里面有关于如何转换代码的说明文档，
00:01:21即如何将 SIG 代码转换为 Rust 代码，
00:01:23如何移植那些代码、翻译表，
00:01:27以及一些通用指南。
00:01:28稍后我们会回到这个文件是如何创建的话题，
00:01:30因为当然，其中涉及到了人工智能，
00:01:32正如你可能猜到的，我们之后会细说。
00:01:34这事儿被发现了。
00:01:36因此，Hacker News 和 X 上自然引发了讨论。
00:01:40也有人讨厌 Rust。
00:01:43还有人厌恶“一切都应重写为 Rust”的观点，
00:01:46因为你经常读到人们希望
00:01:47将程序 XYZ 重写为 Rust。
00:01:52我明白这很烦人。
00:01:55但很自然地，因此，
00:01:57那里存在着大量的两极分化。
00:01:58但在那时，移植工作尚未真正发生。
00:02:00这种情况在五月后期发生了改变。
00:02:035月14日，官方发起了一个合并请求，
00:02:06并最终被合并，
00:02:08它真正将 BUN 代码库
00:02:09全部从 SIG 迁移到了 Rust。
00:02:11正如你所见，这是一个巨大的合并请求。
00:02:15超过一百万行代码被添加进来。
00:02:16而 SIG 代码的移除发生在另一个阶段。
00:02:22所以，这就是为什么它不是一次简单的交换。
00:02:24但这是一个巨大的变化，如你所见，
00:02:28包含了近 7000 次提交。
00:02:30当然，这些代码并非完全由人工审查。
00:02:32它是由人工智能审查的。
00:02:35它通过了测试，但没有经过人工审查。
00:02:39我们稍后会回到关于人工智能是如何被使用的。
00:02:40但它已经被发布或合并了。
00:02:42当然，更多的讨论随之而来。
00:02:44正如我刚才提到的，它没有经过人工审查。
00:02:46在那个时间框架内，这当然是不可能的。
00:02:51但社区深入参与其中，仔细查看
00:02:52并分析了部分内容。
00:02:54随后，BUN 团队发布了另一篇博文或声明，
00:02:59而非关于所有细节的官方文章，
00:03:02专门讨论了对 unsafe 的使用。
00:03:06因为在此合并请求之后出现的一个主要批评是，
00:03:08其中的 Rust 代码不是地道的 Rust 代码。
00:03:10如果从头开始构建，这并非你会写或应该写的 Rust 代码。
00:03:14相反，它实际上就像是从 SIG 到 Rust 的翻译。
00:03:17这意味着并非所有 Rust 的最佳实践
00:03:19和模式都被使用。
00:03:23特别是，其中存在相当数量的
00:03:25unsafe 的使用。
00:03:29要理解 unsafe，你必须理解
00:03:32因为这次合并请求提出后，出现了一个很大的批评声
00:03:37即其中的 Rust 代码并非地道的 Rust 风格。
00:03:41这并不是如果你从零开始构建时，会写或应该写的 Rust 代码。
00:03:44因为在大多数语言中，你要么有垃圾回收机制，
00:03:46相反，这实际上更像是把 C 语言翻译成了 Rust 代码。
00:03:50这意味着并没有充分运用 Rust 的最佳实践
00:03:54并释放内存的过程，这很方便，
00:03:55但会消耗额外的资源。
00:03:58或者你必须自己动手。
00:04:00例如在 C 语言中，
00:04:03你必须手动分配和释放内存。
00:04:05SIG 也是如此。
00:04:08你可以在那里分配内存，但你还必须调用 free
00:04:10或者在不再需要时手动释放它。
00:04:14你可以使用 defer，这很好。
00:04:16这基本上意味着你可以在它实际执行之前
00:04:19调用它。
00:04:21它会被延迟，并会在该作用域结束时
00:04:24自动调用。
00:04:26这很棒，因为在不同的情况下，
00:04:28某个值可能不再需要了。
00:04:31但当你必须手动清理内存时，
00:04:33有很多情况
00:04:37可能会让你搬起石头砸自己的脚。
00:04:40你拥有更精细的控制权，
00:04:43这可能非常有用、非常高效，
00:04:47但在更复杂的程序中，
00:04:49也很容易忘记清理内存的场景，
00:04:52从而导致内存泄漏，
00:04:55这很好，因为在不同情况下
00:04:58某个值可能不再被需要了。
00:05:00但即便如此，当你必须手动清理内存时，
00:05:04Rust 有着不同的方法。
00:05:05在 Rust 中，你有一个名为“所有权”的概念，
00:05:07这意味着每个值都有且仅有一个所有者，
00:05:09并且它与作用域相关联。
00:05:11因此，如果你有一个作用域，
00:05:15你可以使用大括号来创建作用域，
00:05:16或者一个函数也会有它自己的作用域。
00:05:19你可能从 JavaScript 中了解过这个概念。
00:05:20如果你有作用域，
00:05:23那么当一个值在其中被创建时，
00:05:25它就归该作用域所有。
00:05:27而如果作用域结束，它就会被释放。
00:05:30这当然非常方便，
00:05:32因为你不需要操心如何释放它。
00:05:36你也没有垃圾回收机制。
00:05:38相反，你有这样一个明确的规则。
00:05:39在需要传递值的复杂程序中，
00:05:41这可能会导致复杂性。
00:05:43你可能在 JavaScript 中了解过这个概念。
00:05:46但这需要一种不同的思维方式。
00:05:47但当然，它为你提供了内存安全性，
00:05:49除非你使用了 unsafe 关键字。
00:05:51如果你使用了它，你可以创建一个 unsafe 作用域。
00:05:53在那里，这些规则不再适用。
00:05:55而确保内存得到妥善管理就是你的工作了。
00:05:58那么，为什么要这样做呢？
00:06:00嗯，举个例子，
00:06:02如果你正在引入一些 C 语言库，
00:06:05你可以在 Rust 中做到这一点，
00:06:07你可以混合使用一些 C 代码，
00:06:08或者调用一些 C 库的方法和函数，
00:06:11由于 C 本身是不安全的，
00:06:14你接触那些 C 代码的地方也是不安全的。
00:06:19所以你需要该特性来与不安全的代码进行交互。
00:06:22这也是他们在官方声明中指出的事情，
00:06:24代码库中所有这些 unsafe 的使用，
00:06:26很大一部分实际上与对其他库、C 库等的调用有关，
00:06:28这一点是不会改变的。
00:06:29但他们也识别出了
00:06:31可以改进代码并摆脱 unsafe 的领域。
00:06:33他们提到他们会在后续的合并请求中做到这一点。
00:06:34他们确实做了，并且仍在做。
00:06:37所以你可以把这次初步移植看作是一个起点，
00:06:40之后会随着时间推移得到完善。
00:06:44值得一提的是，这个最初的合并请求，
00:06:48或者说那个巨大的合并请求，
00:06:52已经有了通过的测试。
00:06:54所以它是稳定的，测试也通过了，
00:06:56但代码质量并不是你期望用 Rust
00:07:00从头编写的那种质量，因为那不是目标。
00:07:04所以那是 5 月 21 日的情况。
00:07:07然后一切归于沉寂。
00:07:08值得注意的是，这个版本的 BUN 尚未发布。
00:07:10在我录制这段视频时，它还没有上线。
00:07:13你现在安装的依然是 SIG 版本，
00:07:14但这随时可能会改变。
00:07:15但在 7 月 8 日，
00:07:18官方发布了博文，
00:07:20我们在那里找到了关于这次移植的许多有趣细节。
00:07:22非常值得一读。
00:07:24我会把它链接在下面，
00:07:26因为有很多东西值得学习。
00:07:28整个移植过程，这并不是什么秘密，
00:07:30是在人工智能的帮助下完成的。
00:07:32值得记住的是，BUN 是 Anthropic 旗下的。
00:07:35因此，他们可以免费使用所有这些 Token，
00:07:37尤其是在 Fable 5
00:07:40向公众发布之前就使用它。
00:07:43这次移植是用 Fable 5 完成的。
00:07:45顺便说一下，如果你现在安装 Cloud Code，
00:07:46即使 BUN 1.4（Rust 版本）尚未发布，
00:07:49Cloud Code 已经在运行在
00:07:50一个未发布的 BUN 版本之上了。
00:07:52顺便提一下，
00:07:54即便 BUN 1.4 Rust 版本尚未正式发布，
00:07:56Cloud Code 实际上已经运行在
00:07:58某个未发布的 BUN 版本之上了。
00:07:59这是一次极其重大的技术迁移，
00:08:02对整个前端开发领域都产生了不小的震动。
00:08:04这不仅仅是语言的变化，
00:08:06更是工具链生态的一次重大进化。
00:08:07随着后续版本的迭代，
00:08:08我们期待看到更多性能上的提升。
00:08:11最后，让我们持续关注官方动态。
00:08:13是借助人工智能完成的。
00:08:15值得一提的是，Bun 隶属于 Anthropic。
00:08:18所以他们可以免费使用所有这些 Token，
00:08:22特别是在 Fable 5
00:08:24公开发布之前就能使用。
00:08:26此次移植正是使用 Fable 5 完成的。
00:08:29顺便说一下，如果你现在安装 Cloud Code，
00:08:32尽管 Rust 版本的 Bun 1.4 尚未发布，
00:08:36Cloud Code 其实已经在运行
00:08:39在未发布的 Bun 版本之上了，也就是说，
00:08:42那是 Rust 版本。
00:08:44情况就是这样。
00:08:45但确实，这次移植是用 Cloud Code 完成的，
00:08:48基于 Fable 5，当然使用了免费的 Token，
00:08:52因为 Bun 本身就是 Anthropic 的一部分。
00:08:54这一点很重要，要记住，
00:08:56因为在那篇博客文章中，
00:08:58我们了解到，如果你把所有这些 Token 加在一起，
00:09:03或者如果你把所有消耗的 Token
00:09:04按 API 价格计算的话，
00:09:08整个移植过程将耗资约 16 万美元。
00:09:13这是一个惊人的数字，但实际上，
00:09:18如果你考虑到这个项目的规模，
00:09:20规模是 Bun 拥有 53.5 万行 SIG 代码，
00:09:26如果你考虑到这种规模，
00:09:28以及人类将这些移植到 Rust 需要多长时间，
00:09:32那么 16 万美元听起来可能并不算太糟，
00:09:36具体取决于你所在的地区。
00:09:38尽管如此，很明显，没有任何开源项目
00:09:43能够做到这一点。
00:09:44而且大多数公司可能也没有能力
00:09:47或不愿意在移植上花费这笔钱。
00:09:50这之所以可能，是因为 Bun 隶属于 Anthropic。
00:09:54当然，这对 Anthropic 来说也是一个很好的营销噱头。
00:09:58这可能不是主要目的。
00:09:59我不知道是不是。
00:10:03但这当然是一个很好的营销。
00:10:04所有这些都值得牢记。
00:10:06尽管如此，在那篇博客文章中，
00:10:08我们可以了解到 Jared 是如何完成该移植的，
00:10:10或者他是如何让该移植工作起来的。
00:10:14这一切都始于那个移植 Markdown 文件，
00:10:18这是他在与 Claude 的讨论中创建的，
00:10:21在长达三小时的讨论中，
00:10:25正如他在博客文章中所提到的，
00:10:26他本质上是与 Claude Code
00:10:28以及 Anthropic 模型共同决定了
00:10:32这样的移植 Markdown 文件需要是什么样子，
00:10:35才能将 SIG 代码翻译成 Rust 代码。
00:10:37然后，一旦他对此进行了迭代并感到满意，
00:10:40他最初在三个文件上进行了测试。
00:10:44一旦他对结果感到满意，
00:10:46他就让 Claude 开始处理整个 Bun 代码库。
00:10:48在博客文章中，
00:10:53他明确表示，他不仅仅是提示 Claude
00:10:54重写 Bun 和 Rust，不要误解，
00:10:57而是建立了一个复杂的系统，
00:11:00其中有一个主代理，
00:11:03当然也会启动子代理，
00:11:07根据移植 Markdown 文件执行移植。
00:11:09然后，他还有两个对抗性审查代理，
00:11:13它们在主代理完成工作后对其进行审查，
00:11:16并提供反馈，
00:11:19还有一个用于应用反馈的修复代理。
00:11:21他让这一切都在循环中运行，
00:11:24当然还分布在多个工作树中，
00:11:25并自然地分布在多个工作树中
00:11:30以处理整个代码库
00:11:33在博客文章中，
00:11:35他提到他用 Rust 重写了 Bun，
00:11:35使用了 Claude Code 中的 50 个动态工作流，
00:11:38这些工作流在 11 天的时间里
00:11:40启动了大量子代理。
00:11:43他在那里也有一张很棒的图表。
00:11:46总的来说，在博客文章中，
00:11:48里面有一些精美的图片，
00:11:49使内容更容易理解，
00:11:51让内容更容易理解，
00:11:53展示了所创建的提交数量
00:11:56以及在不同日期推送的情况
00:11:58所以这一切都是在 Claude Code 的循环帮助下发生的，
00:12:00这一切都是在 Claude code 的循环帮助下完成的，
00:12:04以及许多子智能体的协助下。
00:12:05审查代理和修复代理的明确流程的帮助下。
00:12:08然后，他还走了另一条单独的道路，
00:12:10也就是让所有这些测试都能工作。
00:12:15这带来了它自己的挑战，
00:12:20因为测试套件非常庞大且复杂，
00:12:22以至于他遇到了各种基础设施限制，
00:12:25因为有些测试消耗大量内存，
00:12:29而且并行运行许多测试，
00:12:31因此行不通。
00:12:33但最终，他也在人工智能的帮助下让这一切得以实现，
00:12:34运行测试，修复代码，
00:12:39重新运行测试等等。
00:12:42所以涉及大量的循环、大量的代理和子代理，
00:12:43自然地，还消耗了大量 Token。
00:12:47消耗了 16.5 万美元的 Token。
00:12:49现在，同样地，你可以深入研究，
00:12:53如果你对所有细枝末节感兴趣，
00:12:55我建议这样做。
00:12:57这是一篇记录了实现这一目标过程的非常棒的博客文章。
00:12:59但简而言之，这就是移植在 11 天内发生的过程，
00:13:03所有这些代理和子代理分布在多个工作流中，
00:13:0850 个这样的工作流，正如我们所了解的，在 11 天内，
00:13:12按 API 价格花费了 16.5 万美元的 Token。
00:13:17现在，最后，在博客文章完成后，
00:13:24他提到 Bun 1.4 修复了最后一个 SICK 版本存在的一些错误，
00:13:29它更节省内存，体积更小。
00:13:35正如我们从 SICK 的创建者 Andrew Kelly 的回复中了解到的，
00:13:38其中一些改进可能也本可以用 SICK 实现。
00:13:43但那篇博客文章非常有趣，因为它经过了编辑。
00:13:47现在的愤怒情绪比最初要少。
00:13:53第一个版本充满了人身攻击，
00:13:57然后再说它并非意在人身攻击，
00:14:00但它确实充满了人身攻击。
00:14:03最新版本，我也会在下面提供链接，仍然相当辛辣。
00:14:05最终，你可以清楚地从阅读第一个版本中看出来，
00:14:11但也包括这个版本，
00:14:14SICK 的创建者 Andrew 和 Bun 的创建者 Jared，
00:14:16他们不会再成为最好的朋友了。
00:14:21现在，他感谢 Bun 支持 SICK，包括经济上的支持，
00:14:26却基本上对整个移植过程大发雷霆，认为如果 Bun 的代码是用正确的 SICK 编写的，
00:14:31它本来是不必要的。
00:14:41他非常清楚地表明，他觉得 Bun 仓库，
00:14:44即 SICK 版本，代码质量不高，这导致了许多问题。
00:14:48这可能是真的，也可能不是。
00:14:53我认为，在 Bun 这种规模的项目中，
00:14:56以 Bun 移动的速度移动，
00:15:01代码质量可能没有达到 SICK 创建者的标准，这是绝对可能的。
00:15:06你当然可以说大多数代码项目
00:15:12并不一定拥有最高的代码质量。
00:15:15不过，你完全可以说大多数代码项目
00:15:18都不一定拥有最高的代码质量。
00:15:21我觉得回复的博客文章相当薄弱，
00:15:24因为它充满了愤怒。
00:15:29它有一些有效的观点。
00:15:33例如，在 Jared 制作的博客文章中，
00:15:35他提到从 SICK 到 Rust 的移植得到了验证，
00:15:40当然，是通过所有这些审查代理，
00:15:46但也通过运行测试套件并使其工作。
00:15:48而 Andrew 正确地指出，当然，相同的测试套件
00:15:51应该或不应该足以证明 SICK 版本是伟大的。
00:15:56所以也许测试套件也应该改进。
00:16:00无论如何，这两个人绝对不会成为最好的朋友。
00:16:04对于 SICK 或 Rust 是否是通用的或对于 Bun 来说是更好的语言，我没有观点。
00:16:09然而，我相信，借助人工智能，Rust 及其内存模型，以及
00:16:17你会因许多内存相关问题获得编译时错误，这是一个巨大的优势，
00:16:23特别是在人工智能时代，因为，当然，整个移植在人工智能的使用方面非常令人印象深刻。
00:16:30当然，这是一种我们大多数人无法负担
00:16:38或在公司中不愿负担的人工智能使用方式。
00:16:41但令人印象深刻的是，AI 能够做到这一点。
00:16:45而且这不是 Vibe 编码或仅仅是 YOLO 提示。
00:16:48这一切背后都有一个明确的流程。
00:16:52投入了大量思考，我希望我已经解释清楚了，如果你深入研究细枝末节的技术细节，这一点也绝对会变得清楚。
00:16:56但在所有的规划、所有的设置迭代、这种方法下，
00:16:59显然这不仅仅是扔给它一个提示。
00:17:05然后我们将看到我们在哪里得到这个展示了你可以用 AI 做什么。
00:17:08当然，将代码库从一种语言移植到另一种语言是 AI 的一个相当好的用例。
00:17:13如果你考虑一下，AI 当然会在编写新代码时挣扎。
00:17:17它可能不会编写你想编写的代码，不遵循你想遵循的代码约定
00:17:21当然，将代码库从一种语言移植到另一种语言，是人工智能非常好的一个应用场景。
00:17:27仔细想想，人工智能在编写新代码时确实可能会遇到困难。
00:17:32它写出的代码可能不是你想要的，也不一定遵循你预期的代码规范或风格
00:17:36巨大的优势是你有代码库供 AI 查看和翻译，
00:17:40这是 AI 可以做的事情，而且你有测试套件。
00:17:43所以有很多东西可以建立。
00:17:47这似乎是 AI 的一个很好的用例，正如这次移植所明确证明的那样。
00:17:53我认为这是这里最有趣的收获。
00:17:57也说明你可以处理以前不可能处理的项目。
00:17:59再次，不是每个人都这样，但对于某些特定规模的公司。
00:18:04这可能很有趣。
00:18:08在 AI 的帮助下现代化遗留软件可以是或可能是一个很好的用例。
00:18:12这表明并证明了这一点可以做到。
00:18:13现在，当然，Bun 1.4 还没出来。
00:18:18我们会看看一切是否会崩溃，他们是否必须在一个月后恢复。
00:18:19你不能完全排除它，但我个人不认为这会发生。
00:18:26它已经被一些早期采用者在生产中使用，例如 Cloud Code CLI。
00:18:30它经过了广泛的测试和审查，尽管当然是由 AI 而非人类审查员进行的。
00:18:32但我非常有信心这将奏效，我认为这是一个非常令人印象深刻的壮举，也是对人工智能的非常令人印象深刻的使用。
00:18:36但一如既往，我也对你对所有这些有什么想法很感兴趣。
00:18:40另外，它已经被一些早期采用者在生产中使用，就像 Cloud Code CLI 一样。
00:18:47它经过了广泛的测试和审查，尽管当然，是由 AI 而非人类审查者进行的。
00:18:54但我非常有信心这会成功，我认为这是一个相当令人印象深刻的壮举，也是对人工智能的一个相当令人印象深刻的用法。
00:19:03但一如既往，我也很想听听你对这一切有什么想法。