大家五一假期愉快！
昨晚睡前无意识网络闲逛，发现了 Brian Anderson 于 2021 年 5 月 2 日 撰写的文章 Rust’s Most Unrecognized Contributor。文章或许存在争议，但文笔很棒，我们也可以多看多思：作为成年人，我们都晓得，任何伟大的背后，无一例外都沉积着丰厚的、但举足轻重的不知名，或者说默默无闻。笔者不由得希望将此文分享，共同向诸多先行者致敬。
以下为原文翻译——
我认为：Rust 语言是一个伟大的成功。当我回想起来的时候，我感到敬畏：有那么多的事情要去寻找正确的方向，才能驻足于我们现在的位置。有那么多的犯错机会，使得 Rust 语言经历了许多微小的奇迹，才变成现在的样子。然而，这些奇迹并不是偶然发生的：每一个奇迹都是由真实的个人创造的，而每个人的精心策划，才使得 Rust 成为伟大的技术。
有许多人，促成了 Rust 的成功。但是，对 Rust 的成功负有最大贡献的人之一，几乎完全没有得到承认。
Rust 起步于 Mozilla 研究院
2009 年，Mozilla 已经从与谷歌的利润丰厚的搜索交易中，积累了可观的现金储备。据我了解，Mozilla 管理层决定是时候投资这笔钱了，公司进入了快速扩张期。
作为扩张的一部分，Mozilla 创建了一个新的部门，Mozilla 研究院。这个部门的任务独立于 Firefox 产品，专注于尝试雄心勃勃的新想法。同时，与计算机科学相关学术界建立关系。
Mozilla 研究院的第一个大创意就是 Servo，或者说是 Rust。
当时，Mozilla 研究院的领导者之一是 Dave Herman。
Dave Herman，何许人也？
Dave Herman 是一位程序设计语言理论家，也是一位宏学家（macrologist，超级热爱宏的人）。同时，他也是 Mozilla 在 ECMAScript 委员会的代表之一。他和创造 Rust 的工程师 Graydon Hoare，都曾合作开发过 ECMAScript 4 标准（遗憾的是，ECMAScript 4 后来被废弃了）。
他们都对创造新的编程语言，有很大的兴趣。
除了 Servo、Rust 和 Dave Herman，在 Mozilla 研究院还发生了很多事情，但我们今天不谈及。
我们聊一聊关于 Dave Herman 是如何悄悄地塑造 Rust 项目的故事。
Dave Herman 对 Rust 的贡献
虽然，Rust 是在 2010 年 6 月发布的，但实际上，Mozilla 内部的 Rust 工作是在 2009 年底开始的。唯一公开的 Rust 发展记录，存在于 Rust 史前（rust-prehistory）仓库。
在 2010 年 6 月之前的数月里，人们争相向公众展示 Rust。Dave Herman 就是其中之一：
代码语言：javascript复制~/rust-prehistory $ git shortlog -sn
1156 Graydon Hoare
163 Andreas Gal
104 Dave Herman
59 graydon@pobox.com
55 Patrick Walton
37 Graydon Hoare ext:(")
13 Roy Frostig
9 graydon@mozilla.com
6 Brendan Eich
5 Michael Bebenita
1 Brian Campbell此后，他将编码工作交给了 Graydon 领导的 Rust 团队。但后来几年的 Rust 开发中，Dave 一直在参与。
那时，大多数 Rust 语言的开发者，实际上都在同一个办公室工作（除了最著名的 Graydon，他远程工作）。他们经常聚集在 Mozilla 山景城（Mountain View）总部的某一个小会议室的桌子旁：一小群全职员工、一大群实习生，以及 Dave Herman。
我猜想，Dave Herman 认为自己是一个导师，根据自己使用 ECMAScript 的经验和自己对语言设计的兴趣，轻轻地推动团队朝着富有成效的方向发展。Dave Herman 从来没有以任何方式行使过权力，直到今天，他也没有试图要求过任何有关 Rust 的荣誉。
Dave Herman 几乎完全是在幕后做着贡献，温和地发挥自己的影响力。
在那个会议室里，有许多早期的基本辩论。当然，今天看来无关紧要的、琐碎的事情，比如：“从函数返回的关键字是什么？”；或者不那么琐碎的事情，比如：“你如何安全地持有一个指向结构体字段域的指针？”。那个时候的问题，今天觉得遥远而不重要，但那是因为当时这些问题被深入地讨论过。Rust 语言被反复地塑造、重塑，直到所有的小问题都被解决，形成一个一致的整体。在会议室里面，Dave 是为数不多的在设计真正的产品化编程语言方面有经验的人之一。如果没有 Dave 指导团队克服这些微不足道的语言设计障碍，Rust 肯定会一团糟。
Dave 的品味塑造了团队的品味，从而塑造了 Rust 语言。所以大部分时间，Dave 对团队的决定都很满意。
Dave 不止对所有早期的 Rust 设计主题有发言权。Rust 语言的关键设计中，Dave 所指导的有很多。如果你对 Rust 有了解，我想你会很熟悉这些设计主题：
- 教授（Pedagogy），即 Rust 的“教学方法”。
Dave 有学术背景，总是根据如何教授和理解来考虑每一个 Rust 语言的设计决策。
- 治理（Governance），以及社区管理。
Rust 从一开始就被设计成一个社区项目。我认为，在很大程度上，是受到了 Dave 个人经验的影响。人们一直认为：最成功的语言不是由一大群人和公司拥有的，而是由他们自己的兴趣和动机共同设计的。
正因如此，在 Rust 形成过程中的每个设计，在当时总被认为是合理的。举个例子，Rust 最早的发展过程，在公开的会议纪要中都有记载。我认为这几乎完全归功于 Dave 自己的纪律性。而且我知道，其中许多记录都是他亲自录制的。
把培养一种语言的社区放在首位，可能是 Dave 最大的遗产。
- 宏（Macros）
如前所述，Dave 是一位宏学家（macrologist）；他是宏方面的专家，有 Racket 语言背景。
代码语言：javascript复制译注：Racket 语言号称“面向‘语言’的程序设计语言”，在灵活的表达式方面非常有特色。但是，括号真的太多了。如下官网示例：
;; Using higher-order occurrence typing
(define-type SrN (U String Number))
(: tog ((Listof SrN) -> String))
(define (tog l)
(apply string-append
(filter string? l)))
(tog (list 5 "hello "
1/2 "world" (sqrt -1)))目前，NSF、微软、谷歌，以及 Mozilla 都对其有帮助。
尽管主要由实习生实现，特别是 Paul Stansifer，以及 John Clements 的一些重要贡献。但是，正因为 Dave，Rust 才拥有强大而健康（hygienic）的声明宏（macro_rules!）。
虽然，这完全不是我参与的领域，但我记得 Dave 和 Paul 花了很多时间讨论：如何在类 Lisp（Lispish）传统中设计健康的宏系统，使得 Rust 栖息于类 C 语言世界。
- Dave 参与的其它关键决策包括：
- 将 Rust 语言从语句语言转换为表达式语言；
- 雇佣 Niko 设计 Rust 的所有权（ownership）系统；
- 雇佣 Yehuda Katz 设计 Cargo；
除了这些显而易见的贡献之外，Dave 还在 Rust 中扮演了另一个重要角色：成为 Rust 在 Mozilla 管理层中的代言人。
在所有致使 Rust 成功的奇迹中，也许最伟大的是 Mozilla 为此付出了许多。但是，Rust 存在于 Mozilla 的整个期间中，Rust 团队有一种明显的感觉，即项目随时都可能被取消。尤其是当 Brendan Eich 离开 Mozilla 之时，情况更是如此。这就是为什么在语言上建立一个强大的社区如此必要的原因之一——时间会冲淡一切。
不过，Dave 是个 Rust 信徒，是代表 Rust 在 Mozilla 的最高职位。他竭尽所能宣传 Rust 对 Mozilla 使命般的重要性，以保持 Rust 的人员和资源配置。真的，我不知道 Dave 在管理岗位上处理了什么，但这绝对是关键所在——他为了让整个“球队”能够专注于 Rust。
不管怎样，Rust 总是人手不足。我记得当时对此非常愤怒：全职工程师却如此之少，我们怎么能与谷歌和苹果竞争？这个问题的一半答案当然是培养投资和多样化的贡献者社区，但这是一个缓慢和不确定的过程。解决这个问题的另一半答案还是要感谢 Dave：实习生，非常多的实习生。Rust 的实习生通常比全职员工多，他们是由 Dave 雇佣的。Dave 可以凭借自己在学术界的诚意，轻松招募 PL 人才。这也是 Mozilla 研究院的部分策略。
有一点值得赞赏的事实：Rust 主要是由学生建造的，他们中的许多人在 Mozilla 实习。
关于 Rust 设计的轶事
我觉得应该在此文中，包括一些关于 Dave 设计贡献的个人轶事。首先，想到的是他不同意团队的决定。因此，这不是 Dave 贡献的一个好例子，但也许仍然值得分享。这也是他如何指导团队，同时也相信团队决定的例子。
目前为止，我很难记住确切的细节，但我清楚地记得，有一次 Dave 肯定不同意团队做出的决定：那是在我们引入可变变量、不可变变量绑定之间的区别时。我们只是在决定何种语言使用何种语法，一件简单的事情。在辩论结束时，有两个明显的选择，分别是不可变绑定和可变绑定：
let和let mutlet和var
第一个选项是我们最终确定的结果，第二个直接借用 JavaScript，这两者都有很好的理由。目前的主要问题是：在两个选项中，选择合适的一种，选择“更难”，或者“更丑”。强制用户键入两个关键字（译注：即 let mut）来创建可变绑定，是语言设计者悄悄地影响程序员，以考虑引入可变性的额外因素。
我记得 Dave 不同意团队在这个问题上的决定。回想起来，我认同他不同意“体罚”用户选择编码模式的原则，但我记不清具体了。不过，我仍然认为团队在这一点上是正确的：额外的 mut，不仅增加了一些额外的工作来增加变量的可变性，而且 mut 自然地扩展到了 Rust 类型系统的其它领域，比如：&mut；而可变性的识别和管理，已经成为语言的一个决定性特征。
给成功以准备
Dave 对于 Rust 设计的直接参与，我想是在 2014 年或 2015 年结束的。可能在 Rust 社区的大多数人，都不晓得 Dave Herman 的存在。
Dave 并未创造 Rust。公开的 Rust 仓库中，他总共仅有 6 次提交（commit）。在邮件列表上，他也只有 4 次发言。
Dave 所做的，是创建一个团队，他相信这个团队能够向世界传递独特的愿景，并在这个团队中巧妙地植入一套价值观。Dave 使得 Rust 语言能够超越了 Mozilla 的边界，超越了任何个人的参与和个性。
事实正是如此。
Rust 成功的原因有很多，从成千上万的贡献者，数千个微小的奇迹，凝聚成一个有条理而一致连贯的整体。
但是，微小的奇迹，并不会偶然变成巨大的奇迹。
谢谢您的阅读，欢迎交流。
