一场会议后，我们CTO全面封杀了Rust！

                
在我们公司，Rust 一开始是梦想中的技术：快速、安全、现代。
我们很兴奋。看了很多博客，看了不少技术大会的演讲，也被无数“把它重写成 Rust”的表情包打动了。于是——我们真的去重写了。
六个月后，我们的 CTO 在全公司范围内禁止使用 Rust。
Rust 能拯救一切？！我们一开始也这么想
我们选择用 Rust 重写的是一个出了名难搞的服务：高流量、高 Bug、高压强。内存泄漏和竞态条件是家常便饭。
“Rust 的内存安全保证能解决这些问题。”团队这样说。
确实没错。重写后，内存问题全都消失了。运行速度也快，扩展性强，所有指标看起来都很棒。
那为什么最后还是被禁了呢？
这些问题，当初没人提醒我们——
1. 开发速度断崖式下跌
重写本身花了三个月，这在接受范围内。但之后的开发就完全变了样。
每个新功能的开发速度都比之前用 Go 或 Python 时慢很多。
新员工上手 Rust 至少需要几个星期才敢碰生产代码。学习曲线太陡了，我们的新人培训效率直接崩溃。

就算是高级工程师，也常常卡在生命周期、trait 限定这些概念上。

总之，Rust 不只是变慢了，更是让团队的某些部分直接“卡壳”了。
2. 招人变成噩梦
我们发布了一个 Rust 后端岗位。结果一个月只收到 4 个申请。而且没有一个人有真正的 Rust 工作经验。
Go？Python？Java？几百封简历随便挑。但 Rust 工程师少、贵，而且往往更倾向于去做开源项目或者加入初创公司，而不是加入一个需要快速扩张的产品团队。
在我们急需扩招的时候，招聘速度严重拖慢。
3. 工具链不够成熟
Cargo 很棒，Clippy 也不错。但除此之外呢？
我们的内部工具坏了；
可观测性集成也需要重写；
DevOps 的自动化大多是围绕 Go 和 JVM 构建的。
我们不得不维护两套技术栈——而问题频出的是 Rust 这边。
4. 重写解决的根本不是核心问题
是的，内存泄漏的问题的确没了。但我们系统的真正瓶颈其实是业务逻辑的复杂度和团队的敏捷性。
Rust 并没有让业务逻辑更容易理解，反而让迭代更困难。产品经理开始感到沮丧，开发速度一落千丈。性价比根本不值。
一场会议，“封杀”Rust

那次 sprint 计划会议，变成了一场关于生命周期 vs RefCell 的争论。

CTO 当场叫停会议，发起紧急评审。
他只问了一个问题：
“如果这不是 Rust，这个功能现在是不是已经上线了？”
全场沉默。
一周后，决定下达：
“Rust 不再被批准用于生产服务。现有的可以维护，但不允许使用 Rust 开发新服务。”
该怪 Rust 吗？
不。Rust 做到了它承诺的事情：安全、快速、零成本抽象。
但我们也意识到：技术选择，本质上是团队选择。
一种对开发者要求极高的语言，并不适合一个以产品为核心、需要快速成长的团队。
我们现在用什么？我们仍然用 Go 来支撑 90% 的服务。
Go 没那么性感，但它足够快、足够安全，最重要的是——团队好扩展。
我们会想念 Rust 的精致吗？偶尔会。但我们后悔封杀它吗？不后悔。
Rust虽好，警惕用力过猛
Rust 是一把好工具——如果你拥有合适的团队、合适的时间、和合适的问题。
但可惜我们，没有这样的团队、时间和问题场景。这就是我们 CTO 在一次重写后封杀 Rust 的原因。
读者中有类似经历的朋友对于文中“封杀 Rust ”的做法表示反对，表示这种做法其实是缺少远见的表现：

“你们遇到的问题，其实很多源于缺乏前瞻性规划。Rust 的确更烧脑，但到了 Go 撑不住的复杂场景，它一样也会变难。

我两个语言都写，最终还是反复回到 Rust——现在连原型都用它写。

Go 的目标很清楚，就是‘赶快上线’，但这不意味着它比 Rust 更优。语言本身没对错，关键在于团队的战略选择和工程成熟度。”
因此，这里值得一提的是，并不是所有团队都认为 Rust 不适合生产环境。另一位读者则指出，很多“Rust 重写失败”的根源，其实是开发者在熟悉 Rust 之后用力过猛，过于追求极致性能，从而引入了不必要的复杂生命周期结构。而如果团队在重写时注意保持设计简洁、避免炫技，Rust 其实是可以很好落地的。正如这位读者所总结的：“保持简单，过程会顺得多。在我参与的几个大项目里，虽然起步难，但回头看是值得的。”



贴主:gonewithsmoke于2025_05_19 9:55:48编辑