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

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

公众号新闻


编译 | Tina、核子可乐
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/307291.html

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

https://mastodon.social/@bcantrill/110453556419668035

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

 活动推荐

FCon 全球金融科技大会将于 11 月在上海开幕,会议聚焦当前金融行业遇到的问题,围绕金融企业在数字化转型过程中的痛点,例如数据治理,智能化、数字化风控,数字化投研,数字化营销,IT 技术能力等方向进行深入交流,扫码或点击「阅读原文」可查看全部演讲专题。

前 100 人可享 5 折特惠购票,咨询购票请联系:17310043226(微信同手机号)。

今日荐文

转型 AI 先裁员?嫌员工技术转型培训太慢裁掉700多人、花200亿美元收购公司,CEO:老顽固们早晚被淘汰!


向量数据库内核面临的技术挑战及应对措施


智谱AI最新估值突破100亿元;红杉减持美团,迄今套现超500亿港币;消息称9月30日前,阿里云将关停代销业务 | AI一周资讯


比 Spark 快 9 倍,超越 ClickHouse,在大语言模型时代构建全新数据平台


比Python快68000倍!Mojo正式发布,网友:Python生态系统最重要的升级来了


解锁大模型落地之道,你最 Pick 哪一个?



你也「在看」吗? 👇

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。
相关阅读
悲观!加拿大央行暂停加息也救不了房市!BMO关闭一项贷款业务+大裁员!黄晓明、蒋欣也救不了这部国剧了?!你不知道的并不等于没发生巴以冲突:穷人是非多,富人机会多注意!纽约时代广场冲突不断!建议提前规划出行秦华×郭兆凡 | 面对现实挑战,内心冲突不断,如何思辨权衡选择?随诗随笔4万一条的镶钻裤衩子外穿也救不了赵今麦的罗圈腿??印、巴宗教冲突不止 教堂遭焚 教会社区受暴力胁迫慌!24fall我没有GRE能申请哪些大学?威马汽车申请破产审查,创始人沈晖被曝已“出走”国外;郭明錤称特斯拉的Cybertruck电动皮卡最快年底前开始交付丨汽车交通日报现金换钥匙赶房客32万亿,耶伦也救不了美国!李佳琦哭着道歉,也救不了国货彩妆破防!清纯小师妹深夜给师兄发信息竟遭拒:求你了!这20个实验protocol我送你!巴以冲突不断,示威者聚集Coply Square集合游行东南亚小家电品牌「Simplus」获新一轮融资,创始人曾任Lazada泰国CEO|36氪首发冲突不同以往!新华社记者现场报道巴以最新情况长篇小说《如絮》第一百五十七章 北京-哈尔滨-1964-1966年 还能怎样离婚也救不了许家印医生也救不了抑郁的青少年:在笼子里养孩子,不疯才怪连她也救不了这片,又一部韩影拉胯?这部剧再疯,也救不了韩女的焦虑𝐂𝐚𝐥𝐧𝐢𝐊𝐞𝐚𝐧双皮奶内衣裤,软弹有度,上身0束缚~吴京也救不了《巨齿鲨2》来自以色列的声音:这里冲突不断,创业活力何来?莫斯科十大著名景点销量暴跌一半,“老干妈”也救不了老干妈刘亦菲的天仙脸也救不了杨洋了吧,还差点反被拖下水...巴以冲突不表态站队?精英大学痛失富豪捐助!Jetbrains发布全新 Rust IDE 命名RustRover,Linux 等可免费下载纽约,修堤坝也救不了的城市国美与黄光裕,谁也救不了谁JetBrains发布独立Rust IDE:RustRover日本一老板曝光越南员工午睡现场:吓死我了!日本网友:羡慕哭了,我也想拥有...
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。