Rust编程语言真把自己玩死了

寂静回声

如果你在 2016 到 2023 年间混过 Reddit、Hacker News 或技术 Twitter，大概率见过那群极其坚定的 Rust 拥趸。
他们最爱喊的一句话就是：
Rewrite It in Rust，最好连 C++ 一起埋了。
在那套叙事里，C++ 程序员像一群拿着裸指针在雷区里狂奔的牛仔。
悬空指针、缓冲区溢出、未定义行为，左侧这些都像定时炸弹。

而 Rust 呢？有 Borrow Checker、有编译期内存安全，还有几乎所有大厂的背书。
甚至美国政府都公开建议关键软件减少使用 C 和 C++，转向内存安全语言。
Rust 连续 8 年拿下 Stack Overflow“最受喜爱编程语言”。

所有人都在说：Rust，就是未来。
时间来到了 2026 年，你再去看看企业招聘，看看真正运行在生产环境里的基础设施。
再看看那些大型科技公司内部的架构复盘，会发现一个很尴尬的事实：这场革命没有按预期继续。
不是因为 Rust 突然不能用了，而是它终于撞上了软件工程里最残酷的东西：经济收益。

Rust 最诱人的承诺一直是：零运行时开销，实现编译期内存安全。
听起来几乎完美,问题是，当年宣传页上很少有人告诉你另一件事：这些复杂度并没有消失。
它只是从运行时，转移到了程序员脑子里。
理论上，Borrow Checker 是守门员。
它帮助你避免：数据竞争\use-after-free\错误生命周期一系列传统 C/C++ 内存问题。
但是，一旦开始构建复杂的数据结构，事情就没那么优雅了。
假设一个最普通的需求：节点 A 和节点 B 需要互相引用。
C++ 的思路很直接：指针,再配合清晰的所有权规则和 RAII。

Rust 呢？你可能开始接触：Arena Allocator、Handle ID、Rc<RefCell<T>>、Arc<RwLock<T>>。
最后你会发现：原本一个非常自然的数据结构，为了让 Borrow Checker 满意，架构不得不跟着变形。
Borrow Checker 最舒服的场景，是清晰、分层、树状的所有权。

问题在于：真正的软件系统不是树。
它们往往是循环的、互相引用的、动态的、关系复杂的。
比如：双向图、侵入式链表、游戏引擎场景树、复杂 UI Layout Engine。
这些结构本来就天然存在交叉引用，于是 Rust 开发者经常被迫进入三条路：

第一种为了满足所有权模型，把架构改成原本并不自然的样子。
例如不用指针，而是把所有对象塞进连续数组，再到处保存 index。
看起来安全了，但本质上，你又重新发明了一套“手动引用系统”。

第二种到处塞Rc<RefCell<T>>或者Arc<Mutex<T>>
安全是安全了，可代码复杂度、锁、运行时检查，也全跟着来了。

第三种最直接unsafe {}既然编译器不同意，那就绕过去。
而这也暴露了 Rust 一个有些尴尬的现实、真正最底层、最追求性能的部分：
Allocator、Async Runtime、Kernel Module、Lock-free Queue、很多地方恰恰离不开 unsafe。
一旦核心逻辑大量进入 unsafe，Rust 原本最漂亮的安全故事，也会开始打折。
你当然仍然拥有更小、更明确的危险区域。
但你已经不能再简单地说：“Rust 从根本上消灭了 C++ 的问题。”
更准确地说是：Rust 把危险压缩到了更少的地方，但没有让危险彻底消失。

软件工程里有一个经常被低估的指标：反馈速度、你改一行代码。
多久能看到结果？几秒？几十秒？还是几分钟？这件事直接影响开发节奏。
而 Rust 最大的问题之一，就是编译太慢。
原文给出的一个中型系统项目示例里：约 15 万行代码。
现代 C++：Clang + C++20 Modules + Ninja。
增量编译：大约 18 秒。
Rust：Cargo + LLVM + Monomorphization + Macro Expansion。
增量编译：大约 3 分 45 秒。
当然，这不是 rustc 团队能力不行。
恰恰相反、问题来自 Rust 本身的设计。
复杂泛型单态化、宏展开、Trait Resolution、Lifetime Verification。
编译器替你做了大量工作、这些工作不是免费的。
程序员最怕的不是慢，是被打断。
假设你修改了一个公共 crate 中的核心结构，在一些现代 C++ 工程中，通过预编译头、Module、合理拆分，增量构建可能很快结束。
Rust 项目里，则触发大量依赖重新编译。
原本只是想确认一个两秒钟就能发现的语法问题，结果编译开始，你起身接水，回来还没完。
顺手看一下手机，再回到编辑器时，你刚才脑子里那条逻辑链已经断了。

很多人低估了“Flow State”有多重要，快速反馈会鼓励你尝试、重构、实验、立即验证。
而等待时间一旦不断拉长，开发就会越来越像批处理任务。
对于大公司来说，也许还能接受。
可对于每天都在和现金流赛跑的创业团队来说：
开发效率，就是钱。
这也是所谓 Rust Developer Tax 最现实的一部分。

如果想理解 Rust 为什么在企业环境里遇到阻力，一个非常典型的案例就是：Rust for Linux。
这是一个极具象征意义的项目、因为如果 Rust 能成功进入 Linux Kernel，并长期稳定运行，就等于证明：
它真的可以在世界上最重要、最复杂的底层 C 项目中生存。
原本这应该是 Rust 的加冕礼、结果却演变成多年磨合。
维护者压力、抽象层冲突、以及大量文化摩擦，一些维护者陆续表达疲惫甚至退出。

原因很现实：
想让 Rust 进入一个已经存在几十年的 C 世界，并不是“换一种语言”这么简单。
你还需要新的抽象、新的绑定、新的工具链、新的维护知识以及一批能同时理解两种世界的人。

这意味着Rust 并不是简单替换 C，很多时候，它会在原有体系旁边，再搭建一套平行基础设施。
在普通应用层，这种抽象成本也许问题不大。
可一旦来到Bare Metal、Kernel、硬件接口、资源极度受限的场景。
每一层额外复杂度，都会变得非常敏感。
编程语言竞争，从来不只是语法竞争。
企业选择一个核心技术栈时，看的还有生态是否稳定、治理是否可预测、未来十几年会不会突然大改方向。

而 Rust 这些年最受争议的一部分，恰恰不是技术。
而是治理、社区、品牌。
原文提到几个长期争议，例如 Rust 商标政策。
曾经的草案因为限制过多，引发社区巨大反弹。
还有社区治理和领导层之间不断出现公开分歧、离职、重组。
与此同时，一部分用户也一直认为 Rust 社区过于强调语言纯粹性和文化议题。
而企业更在乎ABI 稳定性、兼容性、长期维护成本、工程效率。
对个人开发者来说，这可能只是网上吵架。
对 CTO 来说，却完全不是。
一家 Fortune 500 公司选择一门核心语言，有可能要维护：
10 年、20 年、甚至 30 年。
他们喜欢无聊、稳定、可预测。
C++ 的 ISO 委员会很慢、很官僚、甚至让人昏昏欲睡。
但恰恰因为如此：企业知道它不会明天突然翻桌。

Rust 当年最危险的一个假设就是C++ 已经老了。
问题太多、注定被替代。
但它忽略了一件事：C++ 也在进化。
C++98 / 03到 C++11 / 14 / 17再到 C++20 / 23，然后是 C++26。
这已经不是 90 年代那个到处裸 new、裸 delete 的 C++ 了，现代 C++ 这些年发生了很多变化。
例如：td::unique_ptr、std::shared_ptr、RAII、Concepts、Coroutines、Modules、Ranges、Contracts
再配合Clang Static Analyzer、MSVC 的 Lifetime 相关分析、AddressSanitizer、CI/CD 自动扫描。
很多过去只能等到线上崩溃才发现的问题，现在早就可以在开发阶段被检测出来，这件事直接改变了企业的 ROI 计算。
假设你已经有一个稳定运行十年的 C++ 引擎，里面包含几百万行代码。
工程师熟悉、生态成熟、工具完善。
现在有人说：
“我们花 5000 万美元，用三年全部改成 Rust，这样可以减少一部分内存安全问题。”
管理层会问：为什么？
如果通过现代 C++、静态分析、ASan、更严格的代码规范，也可以解决大量风险。
那整套重写的商业价值在哪里？
这就是 Rust 最麻烦的地方，不是它不够好，而是：
替换一个已经足够好的系统，成本可能高得离谱。