写点什么

人红是非多!Rust 社区冲突不断,创始人:别 Call 我了,我也救不了!

  • 2023-09-12
    北京
  • 本文字数:3585 字

    阅读完需:约 12 分钟

大小:1.76M时长:10:14
人红是非多!Rust社区冲突不断,创始人:别Call我了,我也救不了!

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 恰好给了我这些。”

 

参考链接:

https://twitter.com/sheevink

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

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

https://github.com/oxidecomputer/oxide-and-friends/blob/master/2023_05_30.md

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

2023-09-12 15:006970

评论 1 条评论

发布
用户头像
没网友叫他fork一个再开发一个它理想的语言?
2023-09-12 18:14 · 广东
回复
没有更多了
发现更多内容

DeFi质押流动性挖矿模式系统DAPP开发

V\TG【ch3nguang】

DeFi流动性挖矿 质押挖矿

智定义、易调整,火山引擎DataLeap助力企业轻松实现全流程值班管理

字节跳动数据平台

大数据 数据中台 数据治理 数据安全 企业号 8 月 PK 榜

@Configuration 注解的 Full 模式和 Lite 模式!

江南一点雨

Java spring

四层负载均衡的NAT模型与DR模型推导 | 京东物流技术团队

京东科技开发者

负载均衡 企业号 8 月 PK 榜 四层负载均衡 NAT模型 DR模型

零信任体系化能力建设(5):数据安全与控制跟踪

权说安全

网络安全 零信任

活动回顾|阿里云 Serverless 技术实践营 Serverless +AI 专场

Serverless Devs

阿里云 Serverless 云原生

dapp/defi/lp发行代币流动性质押系统项目开发

V\TG【ch3nguang】

代币 DAPP系统开发 质押挖矿

DBeaverEE for Mac(数据库管理工具) v23.2.0激活版

mac

数据库管理工具 苹果mac Windows软件 DBeaverEE

【VLDB 2023】基于预测的云资源弹性伸缩框架MagicScaler,实现“高QoS,低成本”双丰收

阿里云大数据AI技术

#人工智能

R语言之处理大型数据集的策略

timerring

R 语言

如何有效进行RLHF的数据标注?

Baihai IDP

AI 强化学习 数据标注 RLHF 大语言模型

Docker 搭建Web服务器nginx

霍格沃兹测试开发学社

解锁安全高效办公——私有化部署的WorkPlus即时通讯软件

BeeWorks

带你上手基于Pytorch和Transformers的中文NLP训练框架

华为云开发者联盟

人工智能 华为云 大模型 华为云开发者联盟 企业号 8 月 PK 榜

计算机网络知识,一文搞定

霍格沃兹测试开发学社

推荐三款适合运维小白的网络监测工具

小魏写代码

生成式AI改变业务流程:自动化、优化、高效

百度开发者中心

AIGC #人工智能 ChatGPT 文心一言

生成式AI:开启智能科技新纪元

百度开发者中心

#人工智能 生成式AI 文心一言

生成式AI:游戏产业的未来发展驱动力

百度开发者中心

游戏 #人工智能 生成式AI 文心一言

Apache Celeborn 让 Spark 和 Flink 更快更稳更弹性

Apache Flink

大数据 flink 实时计算

网络直播源码UDP协议搭建:为平台注入一份力量

山东布谷科技

软件开发 udp 流媒体技术 网络直播源码 用户数据报协议

ios ipa包上传需要什么工具

雪奈椰子

ios打包

Excelize 开源基础库 2.8.0 版本正式发布

xuri

开源 Excel Go 语言 Excelize 开源软件供应链

企业新道路怎么走?火山引擎AB测试助力决策选择

字节跳动数据平台

大数据 ab测试 对比试验 企业号 8 月 PK 榜 数字化增长

生成式AI驱动的数据中心网络变革

百度开发者中心

AIGC #人工智能 ChatGPT 生成式AI 文心一言

合合信息启信宝与全国性股份制商业银行达成合作,聚焦产业链数字化管理

合合技术团队

人工智能 大数据 银行

IPP swap孵化器丨LP质押挖矿丨算力分红丨系统开发解决方案

V\TG【ch3nguang】

DeFi去中心化系统开发

生成式AI:开启全新产业机遇

百度开发者中心

智能客服 AIGC #人工智能 文心一言

DEFI应用开发技术|DApp借贷理财挖矿系统源码逻辑

V\TG【ch3nguang】

DeFi去中心化系统开发 质押挖矿

IPQ5018 vs IPQ4019-IPQ4029 is safer, lower power consumption and faster-Difference wifi5 and wifi6?

wifi6-yiyi

wifi6 wifi5

代码质量,众包项目的关键成功因素

知者如C

代码质量

人红是非多!Rust社区冲突不断,创始人:别Call我了,我也救不了!_开源_Tina_InfoQ精选文章