編輯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

在我們公司，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 其實是可以很好落地的。

正如這位讀者所總結的：“保持簡單，過程會順得多。在我參與的幾個大項目里，雖然起步難，但回頭看是值得的。”

參考鏈接：https://medium.com/@vardhanharsh8428/why-our-cto-banned-rust-after-one-rewrite-f415d2358fe6