Rust, In Sickness & In Health

# Rust, In Sickness & In Health —— 一段与 Rust 的"婚姻" **TL;DR：** 从与 Node 的痛苦分手、到 2018 年深爱上 Rust，再到用 Rust 创办 Oxide Computer Company 并为 illumos 移植 Rust 支持——一位工程师讲述了自己与 Rust 这门语言"结婚"的全过程，以及 Rust 的价值观（严谨性与性能）如何成为一家计算机公司的文化基石。 --- ## 开场：一段婚姻的比喻 演讲者首先道歉：这场演讲里会充斥着婚姻相关的比喻。他结婚 23 年，自认为这段婚姻经营得不错；而他与 Rust 之间，同样是一段相当稳固的"婚姻"。在他看来，每一段好的婚姻故事，往往都始于很久以前的一次糟糕的分手。 在 Oxide，他有一位非常出色的同事 Rain。Rain 在一次一对一谈话中问了一个问题，语气极其善意、毫无指责： > "我一直想问你一个问题——你看起来是个很聪明的人，像你这样的人是怎么会跑到 NodeJS 里去的？" 演讲者的回答是："Rain，我真的很感谢你。"他真心实意地认为，一个以如此善意方式提出的问题，本身就值得感激。 ## 与 Node 的分手：一次价值观的错配 故事要从 2010 年说起。那时他非常热情地投入 Node，但这段关系并没有走得很顺利——那是一段糟糕的感情。到 2014 至 2015 年前后，他们和 Node "分手"了。 到大约 2017 年，一位不幸已经去世的朋友 Charles Beore 在主办 Node Summit 时邀请他去做主题演讲。他的第一反应是拒绝："Charles，这是个坏主意。我对 Node 没有什么好话可说。" Charles 的回答很干脆："那不是更好吗。" 经过仔细思考后他意识到，这其实是一个真正反思"在 Node 上发生了什么、为什么发生"的机会。就像很多次分手一样，问题并不完全出在某一方身上——那是**价值观的错配**。他所秉持的价值观，与 Node 为自己所追求的价值观并不相同。 那次名为《作为价值观的反思》的演讲，成了他认为自己做过的最重要的演讲之一。它让他理清了裂痕从何而来：对于 Joyant 来说，"严谨性"（rigor）这类东西极其重要；而 Node 说到底就是 JavaScript——好比那个钟形曲线的老梗，我们对 JavaScript 有太多期望，但现实就是它是 JavaScript。当"严谨性"与语言的"易上手性"（approachability）发生冲突时，Node 团队每一次都会选择易上手性。 ## 2018 年：爱上 Rust 2017 年，他开始思考下一步。下一步显然就是其他语言——那次演讲中他同时提到了 Go 和 Rust。他当时还没在 Rust 上做过任何实际工作，只是在想：Rust 能不能是下一步？ 到 2018 年，他真正开始深入研究 Rust。演讲中提到，那时他总共只写了大约 40 小时的 Rust 代码，进入 Rust 才几周，却已经发现这东西非常非常有趣。随着研究越来越深，他真的爱上了 Rust。 ### 非词法生命周期之前的日子 如果是在**非词法生命周期**（non-lexical lifetimes）之前就开始接触 Rust，他认为可以在工牌上贴一枚贴纸，写着"我在非词法生命周期之前就在这里了"。因为在那之前，与编译器的关系要复杂得多——会有更多尖叫、更多泪水流满脸颊的感觉。借用检查器和所有权模型当然那时就已经存在，但那确实是另一番光景。 ### 借用检查器之外还有广阔的天地 他意识到的一点是：**所有权模型让他迟迟不敢真正深入这门语言**，而在所有权模型之外，还有很多值得喜爱的东西。所有权模型确实出色，也当之无愧地被视为 Rust 的核心——但他想向 C 程序员同行们发出一个信号：嘿，这里远不止所有权模型和借用这么简单，别让借用检查器阻止你去探索所有那些令人惊叹的东西。 ### 错误处理：干净的水 他整个人生都活在 C 和 JavaScript 的污泥里，所以代数类型（algebraic types）对他来说就像干净的水： > "我打开水龙头，水就直接流出来，我什么都没做，没有经过处理，我喝下去，我不会生病。" 而那些来自 OCaml 或其他语言的人只会问他："你还好吗？"他知道这听起来很可悲，但干净的水真的很棒。Rust 的错误处理在他眼里非常了不起。 他还提到，觉得 Rust 的社区氛围特别棒。 ### 一次意外的性能胜利：B 树与 AVL 树 他当时有一个 C 与 JavaScript 混合的程序——性能关键的部分用 C 写，本质上是一个 C 程序，前面套了一个类似 Node 的前端。他正用 Rust 重写它，在和借用检查器搏斗。当然，他犯了一个错误：试图在 Rust 中实现一个**双向链表**，尽管博客文章上写着"不不，别这么做，你真的不想这么做"。他一边想"是的，是的，我想这么做"，一边又想"不不，其实我不想这么做"，最后进入了一个阶段——"我只想让这个东西能跑起来，然后就结束"。 他意识到自己正在做一些会让性能很差的决定。然后他运行了程序，结果：**它跑得比他写的 C 还快。** > "什么？为什么？" 后来他写了一篇跟进的博客文章解释原因。核心原因是：在 Rust 中，如果你要用平衡树结构，你用的就是 B 树——而他之前用的是 AVL 树。B 树其实是一种比 AVL 树更好的数据结构，只是在 C 中真的非常难用：C 里没有一个好用的 B 树库，因为所有权模型的问题——在 C 中不清楚谁拥有什么，接口会变得非常混乱。而在 Rust 中要让一个组件成为真正的 B 树也很难。显然，B 树是 Rust 标准库每天都在用的东西。这个更好的结构，性能也胜过他手写的 C。 这对他而言就像一记警钟。 ## 决定创业：一个配得上这门语言的想法 在 Joyant 于 2016 年被 Samsung 收购后，他开始规划下一步，并确定了两件事： 1. **他想和 Steve Tuck 一起创业。** 他们在 Joyant 认识了很多年，很早就决定，无论接下来做什么都要一起做。 2. **他想用 Rust 做。** 在还不知道具体要做什么之前，他们就知道自己想用 Rust 做点什么。 他们试过一堆"绝对糟糕"的点子，但这里就不列举了——都很差，都是些小点子。当他们开始认真思考时，逐渐意识到：这门语言真的很了不起，他们需要一个**真正配得上这门语言的想法**，需要做得更大。 最终他们决定的方向，来自一个问题："我们能做什么？如果我们不怕失败，我们会做什么？"——这句话常被归到 Eleanor Roosevelt 名下，但他觉得更像是马克·吐温和本·富兰克林那类人的手笔，很多话都被安在他们头上，所以他也不确定。 答案是：**来一次史诗级的冒险，真正创办一家计算机公司——做机架规模的机器，自己造自己的计算机、自己的交换机，最重要的是，端到端全部用自己的软件。** 这就是他们 2019 年的融资 PPT，一字不差。多年以后回头看，他们确实做到了当初写进 PPT 的事。 ## 名字之争与公司成立 他们需要一个名字，孩子们非常卖力地帮忙。Susanna 当时 6 岁（现在 14 岁），建议叫 **Updown**。事后回头看，Updown 并不算一个坏名字，但显然不适合一家计算机公司——他们并不完全是"有上有下"，在最糟糕的日子里其实是"一路向下"（down down），不过至少名字里还带着一个"上"。 他 11 岁的儿子当时对神话非常着迷，想了一堆神话相关的名字，他喜欢那些点子，但就此略过。他 14 岁的孩子则建议叫 **Michael Scott Paper Company**——向 14 岁的孩子致敬。 就在他们来回讨论时，演讲者提议："要不要用一个 Rust 主题的名字？比如叫 **Oxide Systems**？"然后他立刻道歉："不好意思，我又在 Rust 的兴奋劲儿里了。" 2019 年秋，他们筹集了资金，成立了 **Oxide Computer Company**，于 2019 年 12 月正式开始运营。 ## Rust：一场刻意的、而非行政命令式的押注 把 Rust 放在核心位置是一个非常刻意的决定，因为他们知道：Rust 围绕**严谨性**和**性能**的价值观，会吸引那些对这个问题感兴趣的技术人员。 结果是双向的——有不少人因为是 Rust 优先而来 Oxide，进而对构建一台计算机感到兴奋；也有相当多人因为对这台计算机感兴趣而来，继而对 Rust 感到了兴奋。**Rust 对他们来说是一个非常重要的文化灯塔。** 但他们并没有通过行政命令来强制推行。创办公司时他们心里是有些顾虑的：他不想让人们为工作而选错工具，也确实在思考技术栈的不同层次上究竟会在哪里使用 Rust。他们知道想在技术栈的最底层使用它，也觉得它可能适合几乎所有地方，但希望让人们自己做出决定。 结果很快揭晓：Rust 适合非常非常非常多的地方——事实上，是所有地方。这真的让人非常惊喜。 ## 与 Rust 共同生活的第一课：移植 illumos 与 RFD 26 研究这台计算机上会运行什么宿主操作系统时，第一个要求很明确：**需要一个真正能运行在 CPU 本身上的操作系统**。他们考察了很多不同的操作系统，也认真研究了 illumos。很多人以为 illumos 是一个想当然的选择——他们确实对 illumos 有很多经验，但这并不是一个不假思索的结论，他们真的想探索所有选项。 他们有一种叫 **RFD（Request for Discussion，讨论请求）**的文档机制，非常受 IETF RFC 的启发。关于宿主操作系统的所有结论都写在 **RFD 26** 里。操作系统的一个重要选择标准是：他们认为会用 Rust 重写这个操作系统的很大一部分，因此必须选一个**对内核级 Rust 支持非常友好**的宿主操作系统。另外还有一些操作系统因为它们的各种观点让团队感到紧张。 最终他们认真选择了 illumos，因为他们知道 illumos 对此会很友好——但也意味着需要为 illumos 添加 Rust 支持。 > "你可以通过一个社区对待小社区的方式，了解这个社区很多东西。" illumos 毫无疑问是一个小社区。他们把 Go 移植到 illumos 上时，Go 发明了 **"二级移植"（secondary ports）**的概念，才让他们被接纳进去。"你就会想：嗯，这真是让人振奋，谢谢你们，非常感谢你们费了那么大劲让我那破玩意儿能在非 Linux 系统上运行。"——Go 确实和 Linux 绑得非常非常紧，那是一段非常令人沮丧的经历，一路上磕磕绊绊。 在 Rust 这边，让人沮丧的一点是：你需要整个 crate 生态系统都能正常工作。他们只需要给某个 crate 一个非常简单的一行修复，而该 crate 的维护者说："好的，这没问题，会在下一个版本里发布。"问题在于，整个社区出于各种其他原因并不想发布下一个版本—— > "我就像是闯进了一场婚姻纠纷里。" 好在他们最终度过了那些难关，社区也一直非常支持他们。这是一段不错的经历：有这么多人对这些其他系统感兴趣，这真的很重要。 ## 蜜月期：把 Rust 用到技术栈的最上层 随后，团队迎来了与 Rust 那段漫长的"蜜月期"。这是他与同事 Dico 和 Adam Leventhal 做的一次演讲，时间在 COVID 期间——演讲里他们理的都是自己给自己剪的头发，都挺不错。（相比之下，演讲者在 COVID 期间给自己理的头发就没那么好了。） 这就是他们开始在**技术栈的最上层**使用 Rust 的地方。 --- **Source:** [Rust, In Sickness & In Health — youtube.com via dbremner](https://www.youtube.com/watch?v=3kbPyuAtk7g)