作者| 蒂娜，核子可乐

为什么Rust 有这么多管理问题？如果由它的创始人统治，Rust 会更好吗？事实上，Rust 的创建者Graydon Hoare 曾经问过这个问题：我回答了。如果他统治，事情肯定会发生很大变化，但他认为Rust 不太可能像现在这样“脱离循环”。

Rust 团队冲突不断

几天前，Rust 发布团队成员Jonas Schievink 要求Rust 团队从项目中删除与他相关的所有文件。

“我想，我还想请求Rust 团队从项目的提交中删除我的所有作者信息。”

“我不再希望以任何身份参与Rust 项目。”

Jonas Schievink 还抱怨Rust 的领导团队，认为这些人“破坏了社区项目并扼杀了公众讨论”。

Rust 团队一直处于混乱之中。此前，审查团队集体辞职，以抗议Rust 核心团队。他们认为Rust 核心团队在执行社区行为准则和标准方面做得很差。 Rust 核心团队并不像团队其他成员那样遵守相同的行为准则（CoC），而CoC 似乎已经成为“治理”核心团队的工具。

今年5月，一群Rust领导人暴力更换了RustConf的主讲人，事态升级后许多人逃离。

今年6月，在经历多次治理风波后，Rust项目宣布成立新的顶级治理机构——Rust领导委员会。 Rust 团队的成员共同创建了一个新的RFC 草案，称为“Rust Leadership Council”，其中建立了以下内容：我们撤掉了Rust 核心团队，任命了各个团队的代表，并成立了顶级治理团队。 ”。

“领导委员会”负责组织和安排一些职责不明确的工作，并委托给小组或成员。此外，“领导委员会”还应作为跨团队的协调、组织和问责机构，负责跨团队的工作、规划和长期项目的成功。领导委员会还负责协调项目带来的团队、结构和流程变更，确保高层团队负责，并代表Rust 项目的公众立场。

也许Rust 领导委员会还没有解决当前的混乱局面，所以Jonas Schievink 再次站起来说，“最近RustConf 主题演讲中的卑鄙回应只是最新的例子，而且可能是唯一的方法。”永久解决这些问题就是彻底消灭这些问题的责任者或鼓吹者。”

为什么Rust 有这么多管理问题？如果Rust 由它的创始人来管理不是更好吗？事实上，Rust 的创建者Graydon Hoare 曾经写道，我从我的角度回答了这个问题。如果他做出裁决，方向无疑会发生重大变化，但他认为Rust 不太可能“跳出循环”。像现在。

Rust 最初是由Hoare 于2006 年开始的个人开发项目。但随着Rust 的发展，它吸引了更多的贡献者，并于2009 年获得Mozilla 的正式赞助。

Hoare 表示自己也无法处理好各种冲突

Hoa 在他的个人博客上讲述了这一切。 2023年，他写了4篇文章。第一篇文章谈到了业余无线电技术，第二篇文章则认为公司雇用的维护者往往对为开源做出贡献没有什么热情（雇主常常认为应该引导“维护者”变得真诚。

Hoa 随后连续发表了两篇博客文章，快速概述了Rust 语言的演变。

今年5 月底，Graydon Hoare 在他的博客上回顾了Rust 的诞生。 Hoa 首先告诉读者，“我已经10 年没有参与这个项目了”，所以“请非常小心我说的话，只是把它当作一个在Rust 关键阶段参与开发的人。” “求你了，求你了……”他警告道。 ”

有趣的是，6月份发表的第二篇文章标题为《我理想中的 Rust 不会有未来》（我想要的Rust没有未来，https://graydon2.dreamwidth.org/307291.html）。

首先，霍尔提出了一个人们最近一直在问的问题。 “你有没有想过在你的Rust项目上设置BDFL（终生扮演仁慈的独裁者）？而如果他真的这么做了，你的Rust项目的开发会不会更加顺利？”软件开发领导者，通常是项目创始人，他们在社区内的争议和讨论中拥有最终决定权。

华先生首先明确地回答“不”，并补充道，“我不喜欢关注，也不喜欢公众压力。当我在2009年到2013年担任该项目的技术总监时，我们已经接近这一点了， “ 他加了。这就是极限……而且，我觉得我无法建立一个强大或健康的团队系统并处理某些任务，如决策、冲突、授权、扩展等。 ”

这篇文章后来被发布到了霍尔经常光顾的Reddit 的Rust 子论坛上。有用户询问Rust 项目开发最近是否放缓，Hoa 回答说：“对于主要功能，适当缓慢的开发速度将是有益的。”

Hoare 本人在文章的评论部分说道，“不要让我谈论类型参数上的尖括号或生命周期上的单引号！”

一位Reddit 用户坚持要跟进，其中Hoare 澄清说他“争论过这些语法问题，但最终我输了”，并发布了Rust Prev 的副本，我什至发布了“历史”的链接。 ” GitHub 存储库。几年前。事实证明，Hore 最初是想在类型参数中使用方括号。 “我个人一直认为类型参数应该使用方括号。根本没有必要争论，”他补充道。

Hoare 还反对在引用中显式使用生命周期，他指出“生命周期几乎可以肯定是可以推断出来的，因此无论使用哪种语法，开发人员都不需要单独编写它。”但Rust 显然不这样做。不要求您明确使用生命周期。尽管最终没有成功，“沿着这条路走，”霍尔后来在Reddit 上的评论中感叹道，“有一天我会写一篇关于‘我内心真正的锈迹’的博客文章，我可能会告诉所有人。” rust 和rust 之间的区别。”别误会我的意思，我想象的和实际的Rust 之间有很大的区别。尽管如此，我还是从Rust 语言的成功中感受到了巨大的成就感和满足感。 ”

希望 Rust 变更好

Hoa先生认为口味上有差异。 “我自己的品味非常具体，可能与我的大多数朋友不同。”

他强调，自己内心的锈迹“可能会引起所有参与者的不满，没有办法像现在这样真正破圈……”

“不要误会我的意思，我对结果非常满意。我很高兴业界有C++ 的可行替代品，它为人们提供了新的范式和日常使用的合理选择。我也使用Rust，所以如果能够使用它作为C++ 的替代品那就太好了.

Hoare 在他的文章中还列出了“我特别不赞成和/或目前不喜欢Rust 的事情”。例如，在文章的“复杂语法”部分中，Hoare 抱怨Rust 还不能工作。很难分析。 “它比C++ 更容易使用，但与C++ 本身相比，我发现它很难使用。一开始我也尽力了，但从类型参数中的尖括号到模式绑定中的歧义，再到分号和花括号，一切都失败了。我失败了几乎每个具体问题.我现在不想谈论这个话题，但无论如何，当前的语法与我的预期相去甚远。

另一个例子是Rust 如何处理类型。霍尔本人赞成“结构”类型（即，只要每个对象的结构相同，类型就相互兼容，并且不受其声明中使用的类型名称的影响）。 Hoare 还指出，“Rust 语言本质上带有（并且我希望能够回归）编译器发出的‘类型描述符’，并且用户可以使用这些‘类型描述符’来调用反射运算符。 ”

Hoare 对于Rust 如何处理十进制浮点数也有很多想法。 “基本上，我们意识到每种语言在金融数学方面都有自己的特性，我们最终添加了一个十进制类型，但我最终将它放入了库中。选项，但我认为如果它是内置的会更好。”

还有很多其他的例子，但Hoare 没有列出他的愿景与当今实际Rust 之间的差异。相反，“对当时的各种设计主题表达不同意见很重要。”

霍尔说：“我在研究这种语言时所考虑的优先事项与围绕该语言成长的社区所确定的优先事项存在尖锐冲突。这需要多年的开发时间。即使在那之后，我关注的问题仍然是仍然没有被认真对待。

“我愿意为了简单性而牺牲性能和表现力——，重点是减少最终用户的认知负担，降低编译器的实现难度。我认为这是Rust 的正确发展方向，但事实证明这是与大多数人对Rust 的期望完全相反。

Hoa 先生还提供了相当多的细节。

“Rust 社区中的许多人认为零成本抽象是Rust 语言的核心承诺。我永远不会这么说，而且我个人认为这种机制本质上是有问题的。我觉得这是典型的C++ 思想，并施加了不必要的限制在设计空间上，我更喜欢替换具有更多抽象的所谓更简单、更强大的版本，尽管该语言的实际性能较慢，同样，我也牺牲了许多现代Rust 的表现力。程序员可能会觉得这令人反感，因为他们认为Rust 项目不允许用户在库代码中编写各种函数，我认为这是笨拙和官僚的，就像保姆语言一样，即使使用简单的结构，如变量隐藏、环境捕获和内联函数；是不可靠的。

可以想象，这篇博文一发布到Reddit 上就引发了很多讨论。一位用户透露，“我真的希望我们有Hoare 版本的Rust。听起来太美了。”

然而，另一位评论者似乎对这一变化更加务实，认为“他的Rust 不会更好，它只是会与原来的方式有所不同.”

“今天我更喜欢Rust……我喜欢性能更强、更真实的代码。Real Rust 正是为你提供了这一点。”

参考链接：

Tweets by sheevink

https://graydon2.dreamwidth.org/307105.html

https://graydon2.dreamwidth.org/307291.html

https://github.com/oxydecomputer/oxyde-and-friends/blob/master/2023_05_30.md

https://thenewstack.io/graydon-hoare-remembers-the-early-days-of-rust/

本文转载自：

https://www.infoq.cn/article/6TzaQ6wNB9vd8SJ3RCet