Rust 要变成下一个C++？

大家好，我是Tony Bai。

【导读】

一位Rust开发者在r/rust发帖，列出了十几项正在讨论中的语言提案——命名参数、开放枚举、字段投影、Move/Destroy/Forget trait……他担心Rust正在一步步走上C++ “大杂烩”的老路。帖子迅速引爆社区，连Rust语言团队成员都亲自下场回应。这场争论，或许正是所有“成功的编程语言”都逃不开的宿命拷问。

【文章要点】

• 一石激起千层浪：Reddit r/rust 一篇梳理十几项正在推进的复杂语言提案的帖子引发全网热议，直击“Rust 是否会重蹈 C++ 历史覆辙”的敏感痛点；
• 激增的“焦虑清单”：命名参数、开放枚举、字段投影、Move/Destroy/Forget 三件套 trait、FFI 函数重载等提案密集讨论，引发社区对语法膨胀和语言正交性破损的深层担忧；
• 出圈的“三轴判断法”：高赞神评提出从“广泛 vs 狭窄”、“能力解锁 vs 纯语法糖”、“新特性 vs 填坑做减法”三个维度量化特性的引入价值，成为理性评估新提案的普适标尺；
• 语言团队核心下场释疑：核心成员 Josh Triplett 明确表示团队对复杂度极其谨慎，部分提案旨在消除旧有心智负担（做减法），部分特性（如函数重载）将严格限定范围，而命名参数等更倾向于通过现有特性组合解决；
• 民意与机制的博弈：年度调查显示 40% 的受访者希望优先做简化，而 Rust 历经十年依然保持克制的核心底牌，在于严格且拉长周期的 RFC 流程与“复杂度预算”自检机制。

如果你关注编程语言圈，大概率已经刷到过这条帖子。

今日，Reddit的r/rust板块，一名用户发了一篇题为《My concerns about the future of Rust（我对Rust未来的担忧）》的帖子。

没有惊悚的标题，没有引战的措辞，开篇第一句甚至是：

"我爱Rust，但是……"

但就是这么一篇平静的帖子，硬是炸出了数百个赞和评论，甚至惊动了Rust语言团队的核心成员亲自下场解释。

争论的核心问题只有一个：Rust，会不会变成下一个C++？

一份“焦虑清单”

楼主开门见山地表示，自己并不是反对某一条具体提案，而是担心把所有正在讨论的提案叠加在一起看时，Rust语言会呈现出令人不安的整体趋势。

他列出了一长串正在社区讨论、甚至已经有RFC（提案文档）在推进的语言特性，其中包括：

• 命名参数 / 默认参数
• 句柄类型、use语法糖、Share trait（人体工学式引用计数）
• 开放枚举（Open enums，主打FFI场景，但可能被滥用到其他地方）
• pub(api)可见性修饰符
• 字段访问声明与基于位置的生命周期语法
• 字段投影（Field Projections）
• 显式尾调用 / loop_match
• Sized Hierarchy，在Sized/?Sized之上叠加多个新trait
• 对Drop语义的自定义控制
• super let
• 自动实现（auto impl）
• 面向FFI的函数重载
• 可变参数（Variadic parameters）
• Move / Destroy / Forget 三件套trait
• impl Fn(...)类型里的命名参数

楼主的担忧很朴素：如果这些提案全部落地，Rust将新增几十个关键字和保留字，语法和语义复杂度会大幅上升。而Rust最打动人的地方之一，恰恰是“语言的每一部分都天然契合彼此”——这种正交性一旦被打破，Rust就有滑向“新时代C++”的风险。

他还特别点名了FFI（跨语言互操作）相关的提案：许多复杂改动的出发点是“更方便地对接C/C++代码”，但楼主直言，为了兼容日益过时的语言而牺牲Rust本身的简洁性，这在他看来是一种“本末倒置”。

混战开始：三种态度

帖子发出去不到半天，评论区就自然分成了几派。

第一派：技术限制派。一位用户指出，清单里大多数提案其实源于真实的技术局限，比如显式尾调用能让字节码解释器快出一大截；Drop语义控制解决的是“文件关闭失败”这种现实中确实无解的痛点。这一派的共识是：这些特性大概率只影响特定领域的开发者，平时“眼不见为净”。

第二派：反对复杂化派。这一派用户提出了针锋相对的观点，围绕Move/Destroy/Forget三件套展开了一场高质量拉锯战——有人认为它会让类型系统更复杂，也有人反驳说，这套机制恰恰是为了未来彻底淘汰std::pin这个公认的“复杂度重灾区”，长期看反而是在做减法。

第三派：坚定支持派。这类用户的发言也获得不少点赞，核心观点是：Rust的复杂度和C++的复杂度根本不是一回事——C++的问题在于反复为同一个问题造多个轮子，而Rust的新特性大多是解决彼此独立的新问题，不易牺牲整体一致性。他的结论很干脆：“让Rust更复杂，也就是让Rust更好。”

高赞神评：一套“三轴判断法”

这场讨论里最出圈的一条回复提出，判断一个新特性是不是“甜蜜的负担”，可以从三个维度去看：

1. 广泛 vs 狭窄：一次性解决一类共性问题的“广”特性，比反复打补丁解决单点问题的“窄”特性更值得加。
2. 解锁能力 vs 语法糖：真正“解锁”此前做不到的能力，才配得上增加的复杂度；单纯让写法更顺手的语法糖，性价比要打问号。
3. 新增 vs 修补：有些看似“新特性”的提案，实际上是在“打补丁”——去掉了此前必须硬记在脑子里的例外情况，反而是在给语言做减法。

按这套标准，这条回复明确表示自己并不看好命名/默认参数、闭包里的use语法糖，但会非常支持显式尾调用和可变参数——理由是它们属于“广泛且解锁能力”的类型。

这套框架后来被多位评论者反复引用，成了这场讨论里最接近“共识”的分析工具。

官方下场：语言团队怎么说

最有分量的回复，来自ID为JoshTriplett的用户——他在个人标签里标注了rust、lang、libs、cargo，是Rust语言团队的成员。他特别说明，以下发言仅代表个人，不代表团队整体立场。

他给出的解释大致可以归纳为三类：

• 一部分特性正是为了“简化”而加。比如视图模式（view patterns）之类的提案，解决的是新人从其他语言迁移到Rust时最容易“劝退”的痛点，本质是把用户本来就要自己想办法解决的问题，用更规整的方式收编进语言里。
• 一部分特性团队自己也很谨慎，正在反复权衡怎么落地。他举了函数重载的例子：团队希望把它严格限定在FFI兼容场景，而不是变成C++那种任意重载。
• 一部分特性大概率不会采纳，或者只以“现有特性组合”的方式变相实现。比如命名/默认参数，他透露团队更倾向于鼓励开发者用“结构体参数+默认字段值”的组合方案去解决，因为这只是已有能力的自然延伸，而不是引入一整块全新的复杂语法面。

一组数据：不是孤例

讨论过程中，还有网友甩出了一个佐证：根据2026年3月发布的Rust官方State of Rust年度调查结果，约有40%的受访者表达了与楼主类似的担忧，认为语言应该优先做“简化”而不是“加法”。

这也从侧面说明，这篇帖子戳中的并不是一个人的焦虑，而是一部分Rust用户群体真实存在的集体情绪。

不过也有老用户站出来“降噪”。一位自称从2014年开始写Rust，本人也是servo、rust、clippy等项目的贡献者表示，类似的“塌方警报”几乎每年都会响一次，但过去十年里从未真正发生过——原因是Rust的RFC流程本身就设有相当长的观察期和“复杂度预算”审查机制，大多数提案要经过数年讨论才可能落地，中途夭折的比例极高。

小结

这场讨论最有意思的地方，或许不在于谁对谁错，而在于它精准地呈现了一个悖论：

一门语言越成功、用户越多，等待被解决的“长尾需求”就越多；而每一个长尾需求背后，都有一小撮开发者真心觉得“这个特性必须加，不然我没法用”。楼主在帖子里自己也承认这一点——他并不否认这些提案大多“确实有用”，只是担心把它们全部叠加起来，会不会在某个临界点上，让Rust从“精巧”滑向“臃肿”。

C++用了近三十年时间，才从"简洁的C升级版"变成今天动辄两千页标准、多套编译器实现互不兼容的庞然大物。Rust才十年历史，走到今天这一步是否也是必然，恐怕没人能给出确定答案。

但至少从这篇帖子的讨论质量来看，Rust社区对这个问题的警觉程度，本身可能就是它区别于前辈的地方。

本文编译整理自Reddit r/rust板块讨论串《My concerns about the future of Rust》，原帖及评论区观点归属原作者所有。https://www.reddit.com/r/rust/comments/1wat0px/my_concerns_about_the_future_of_rust/