最新资讯|人红是非多！Rust 社区冲突不断，创始人：别 Call 我了，我也救不了！
发布时间：2023-09-13 15:28:13
Rust 为什么会有这么多管理上的问题？如果 Rust 采用由创始人治理的方式，会不会更好？实际上，Rust 的创造者 Graydon Hoare 曾回应过这个问题，他认为如果是由他来治理的话，事情肯定会很不一样，但是 Rust 就不太可能像现在这样“出圈”。
Rust 团队冲突不断
前几天，作为 Rust 发布团队（Release team）的一员，Jonas Schievink 要求 Rust 团队从项目中删除掉和他有关的所有文件。
“请求将我从‘校友’中删除，并删除和我的用户名绑定在一起的文件”，“我还想请求 Rust 团队从项目的 commits 中删除我所有作者信息。”
“我不想再以任何身份参与 Rust 项目。”
Jonas Schievink 还吐槽了 Rust 领导团队，认为这些人“破坏了社区项目，并压制了公众讨论”。
Rust 团队一直风波不断。此前，还发生过为了抗议 Rust 核心团队（Core team），审核团队集体辞职的事情。他们认为 Rust 核心团队在执行社区行为准则和标准上让自己不受制约。Rust 核心团队并没有和其他成员遵循同样的行为准则 (CoC)，Coc 似乎变成了核心团队 “严于律人” 的工具。
今年 5 月，Rust 领导小组粗暴撤换 RustConf 主题演讲人，事态升级后引发多人出走。
今年 6 月，在经历了多次治理风波后，Rust 项目宣布成立新的顶级治理机构：领导委员会（Rust Leadership Council）。由 Rust 各团队成员合力创建一份新的、名为 “ Rust 领导理事会” 的 RFC 草案，并确立了以下内容：移除 Rust 核心团队，由各团队出一个代表，成立一个顶级的治理团队“领导委员会”。
“领导委员会” 负责一些职责不清的工作安排及其优先次序，然后对这些工作进行精确到子团队或成员的委托。另外，“领导委员会” 还要以跨团队工作、规划和项目的长期成功等为目标，成为团队之间的协调、组织和问责机构。领导委员会还需要协调因项目而导致的团队、结构或流程的变化，确保顶层团队负起责任，并负责展示 Rust 项目的官方态度。
可能“ Rust 领导理事会”还是没有解决好当前的各种乱象，所以 Jonas Schievink 又站了出来：“对最近 RustConf 主题演讲的怯懦处理只是最近的一个例子，而且它也不太可能是最后一个。即使领导结构发生了变化。永久解决这些问题的唯一方法是从 Rust 项目中完全驱逐那些对这些问题负责的人，或者为这些问题辩护的人。”
Rust 为什么会有这么多管理上的问题？如果 Rust 采用由创始人治理方式，是不是更好？实际上，Rust 的创造者 Graydon Hoare 曾从侧面回应过这个问题，他认为如果是由他来治理的话，方向肯定会很不一样，但是 Rust 就不太可能像现在这样“出圈”。
Rust 最早诞生于 2006 年，刚开始只是 Hoare 的个人开发项目。但在发展过程中，Rust 吸引到更多贡献者，并于 2009 年正式获得 Mozilla 的官方赞助。
Hoare 表示自己也无法处理好各种冲突
Hoare 在他的个人博客可以说是无所不聊。2023 年他撰写了四篇文章，第一篇谈的是业余无线电技术，第二篇则是企业雇用的维护人员往往对于开源贡献没什么热情（他认为雇主应该引导这些「维护人员成为真正的维护者」）。
然后，Hoare 连发两篇博文，对 Rust 语言的演变进行了快速梳理。
今年 5 月底，Graydon Hoare 在自己的博客上回顾了 Rust 诞生历程。Hoare 首先提醒读者，“我已经有十年没参与这个项目了”，所以“大家对我的一切言论都请保持谨慎态度，单纯把我看作一位曾经在重要阶段参与过 Rust 发展的当事人就好……”
有趣的是，6 月份发布的第二篇文章题为《我理想中的 Rust 不会有未来》（The Rust I Wanted Had No Future，https://graydon2.dreamwidth.org/307291.html）。
首先，Hoare 提起最近人们执的问题，“你有没有想过在 Rust 项目中 BDFL（终身扮演仁慈的独裁者？）”而如果他真的这样做了，Rust 项目的发展会不会更加顺遂？BDFL 是授予少数开源软件开发领导者的头衔，通常是在社区内的争议或争论中保留最终决定权的项目创始人。
Hoare 首先给出了明确的回复，“不会。”他进一步补充道，“我不喜欢受到关注、也不喜欢公众压力。在 2009 年到 2013 年担任项目的技术主管时，我就已经快到极限了……另外，我觉得自己没办法建立起强大或者健康的团队制度，处理不好决策、冲突、授权和扩展之类的具体工作。”
后来这篇文章被发到了 Reddit 上的 Rust 子论坛中，Hoare 也经常在这里转悠。有位用户询问 Rust 最近的项目开发是否有所放缓，Hoare 回应称“就主要功能来说，开发速度的适当放缓是有好处的。”
而在他那篇文章的评论区中，Hoare 本人表示“千万别让我聊类型参数里的尖括号和生命周期里的单引号！”
有位 Reddit 用户倒是坚持跟进，而 Hoare 澄清说“我们曾经就这些语法问题展开过争论，但最后我失败了。”他甚至公开了一个指向“Rust prehistory”GitHub repo 的链接，其中存放着 13 年前的 Rust 代码。可以看到，Hore 当初是想在类型参数中使用方括号的，他补充说“我个人一直觉得，类型参数就应该使用方括号，根本不需要争论。”
Hoare 还反对在引用中显式使用生命周期，在他看来“生命周期几乎肯定可以推断出来，所以无论具体使用哪种语法，都没必要让开发者单独编写。但很明显，Rust 最后没有顺着这个路子走。”Hoare 后来在 Reddit 评论中感叹道，“终有一天，我可能会写篇〈我心目中的真正 Rust〉的博文，告诉大家我当初想象中的 Rust 和如今真实的 Rust 间其实有着巨大差异。但请别误会，尽管大有不同，但我对 Rust 语言获得的成功仍然抱有巨大的成就感和满足感！”
希望 Rust 变更好
Hoare 认为偏好差异的确真实存在，“我自己的偏好就比较特殊，可能跟大多数朋友有所不同。”
他强调他心目中的 Rust“可能会让所有参与者都不满意，也没办法像现在这样真正破圈……”
“请别误会我的意思：我对现在的结果非常满意。我很高兴行业中有了一种可行的 C++替代方案，它给人们提供一种新的范式、一种可供日常使用的合理选项。我也在用 Rust，也很高兴能有它来替代 C++。但是……”
在文中，Hoare 也列出了“Rust 中那些我特别不认可且/或目前不太喜欢的地方。”比方说，在文中“复杂的语法”这部分，Hoare 就抱怨说 Rust 仍然难于解析。“它虽然比 C++更易用，但跟 C++比较本身就说明它的易用性不足。当初我也努力过，但从类型参数里的尖括号到模式绑定的歧义、再到分号和大括号的使用规则，我几乎在每个具体问题上都失败了……我现在甚至不想再谈这个话题，总之现在的语法跟我的设想相去甚远。抱歉了各位。”
另一个例子，则是 Rust 处理类型的方式。Hoare 本人更偏向“结构”类型（即只要各对象的结构相同，则其类型就相互兼容——不受声明时所使用的类型名称的影响）。Hoare 还透露，“Rust 语言最初带有（我也希望它能再次拥有）编译器发出的「类型描述符」，用户可以在其上调用反射算符。”
Hoare 对于 Rust 如何处理十进制浮点数也有不少想法。“基本上，每种语言都意识到金融数学有其特殊性，并最终添加了小数类型。我希望 Rust 能提前完成这项工作，但最终还是被放进了库里。虽然选项不少，但我觉得能内置的话也许更好……”
还有更多例子，但 Hoare 倒是没有列举他的构想跟现在真实 Rust 之间的差异。相反，“重要的是表达当时在各个设计主题上的分歧。”
Hoare 写道，“我在研究这门语言时考虑的各种优先事项，基本上跟围绕该语言发展出来的社区所认定的优先事项出现了巨大偏差。甚至经过多年发展，我关注的那些问题还是没有得到重视。”
“我会为了简单性而牺牲性能和表达力——也就是更强调帮助最终用户减轻认知负荷、在编译器中降低实现难度。我觉得这才是 Rust 的正确发展方向，但事实证明这似乎跟大多数人对于 Rust 的预期截然相反。”
Hoare 甚至给出了不少细节：
“Rust 社区中的很多人认为「零成本抽象」是 Rust 语言的核心承诺。我永远不会这么讲，而且我个人觉得这种机制本身就有问题。这是种典型的 C++思路，对设计空间造成了不必要的限制……换作是我，会更倾向用大量相对较小的恒定性能成本，来替代包含大量抽象的所谓更简单/更强大的版本，哪怕语言的实际性能会变得更慢。”
“同样的，我也会牺牲掉一部分表达力。但这可能会让很多现代 Rust 程序员感觉不爽，认为 Rust 项目既笨拙又充满官僚气息、像是一种保姆式语言，根本不允许用户在库代码中编写各类功能，甚至不信任程序员用变量隐藏、环境捕捉或内联函数等简单结构。”
大家可以想见，这篇博文在登陆 Reddit 之后，很快引起了各种各样的讨论。一位用户明确表示：“我真希望能拥有 Hoare 设想中的 Rust，那听起来很美。”
但另一位评论者似乎更加务实更改，认为“他的 Rust 不会更好，只是跟现状不同……”
“我倒是更喜欢如今的 Rust……我喜欢性能更高而且脚踏实地的代码，而真实的 Rust 恰好给了我这些。”
