編輯 | 云昭
出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）
在我們公司，Rust 一開始是夢(mèng)想中的技術(shù)：快速、安全、現(xiàn)代。
我們很興奮。看了很多博客，看了不少技術(shù)大會(huì)的演講，也被無數(shù)“把它重寫成 Rust”的表情包打動(dòng)了。于是——我們真的去重寫了。
六個(gè)月后，我們的 CTO 在全公司范圍內(nèi)禁止使用 Rust。
一、Rust 能拯救一切？！我們一開始也這么想
我們選擇用 Rust 重寫的是一個(gè)出了名難搞的服務(wù)：高流量、高 Bug、高壓強(qiáng)。內(nèi)存泄漏和競(jìng)態(tài)條件是家常便飯。
“Rust 的內(nèi)存安全保證能解決這些問題。”團(tuán)隊(duì)這樣說。
確實(shí)沒錯(cuò)。重寫后，內(nèi)存問題全都消失了。運(yùn)行速度也快，擴(kuò)展性強(qiáng)，所有指標(biāo)看起來都很棒。
二、那為什么最后還是被禁了呢？
這些問題，當(dāng)初沒人提醒我們——
1. 開發(fā)速度斷崖式下跌
重寫本身花了三個(gè)月，這在接受范圍內(nèi)。但之后的開發(fā)就完全變了樣。
每個(gè)新功能的開發(fā)速度都比之前用 Go 或 Python 時(shí)慢很多。
新員工上手 Rust 至少需要幾個(gè)星期才敢碰生產(chǎn)代碼。學(xué)習(xí)曲線太陡了，我們的新人培訓(xùn)效率直接崩潰。
就算是高級(jí)工程師，也常常卡在生命周期、trait 限定這些概念上。總之，Rust 不只是變慢了，更是讓團(tuán)隊(duì)的某些部分直接“卡殼”了。
2. 招人變成噩夢(mèng)
我們發(fā)布了一個(gè) Rust 后端崗位。結(jié)果一個(gè)月只收到 4 個(gè)申請(qǐng)。而且沒有一個(gè)人有真正的 Rust 工作經(jīng)驗(yàn)。
Go？Python？Java？幾百封簡(jiǎn)歷隨便挑。但 Rust 工程師少、貴，而且往往更傾向于去做開源項(xiàng)目或者加入初創(chuàng)公司，而不是加入一個(gè)需要快速擴(kuò)張的產(chǎn)品團(tuán)隊(duì)。
在我們急需擴(kuò)招的時(shí)候，招聘速度嚴(yán)重拖慢。
3. 工具鏈不夠成熟
Cargo 很棒，Clippy 也不錯(cuò)。但除此之外呢？
- 我們的內(nèi)部工具壞了；
- 可觀測(cè)性集成也需要重寫；
- DevOps 的自動(dòng)化大多是圍繞 Go 和 JVM 構(gòu)建的。
我們不得不維護(hù)兩套技術(shù)棧——而問題頻出的是 Rust 這邊。
4. 重寫解決的根本不是核心問題
是的，內(nèi)存泄漏的問題的確沒了。但我們系統(tǒng)的真正瓶頸其實(shí)是業(yè)務(wù)邏輯的復(fù)雜度和團(tuán)隊(duì)的敏捷性。
Rust 并沒有讓業(yè)務(wù)邏輯更容易理解，反而讓迭代更困難。產(chǎn)品經(jīng)理開始感到沮喪，開發(fā)速度一落千丈。性價(jià)比根本不值。
三、一場(chǎng)會(huì)議，“封殺”Rust
那次 sprint 計(jì)劃會(huì)議，變成了一場(chǎng)關(guān)于生命周期 vs RefCell 的爭(zhēng)論。CTO 當(dāng)場(chǎng)叫停會(huì)議，發(fā)起緊急評(píng)審。
他只問了一個(gè)問題：
“如果這不是 Rust，這個(gè)功能現(xiàn)在是不是已經(jīng)上線了？”
全場(chǎng)沉默。
一周后，決定下達(dá)：
“Rust 不再被批準(zhǔn)用于生產(chǎn)服務(wù)。現(xiàn)有的可以維護(hù)，但不允許使用 Rust 開發(fā)新服務(wù)。”
該怪 Rust 嗎？
不。Rust 做到了它承諾的事情：安全、快速、零成本抽象。
但我們也意識(shí)到：技術(shù)選擇，本質(zhì)上是團(tuán)隊(duì)選擇。
一種對(duì)開發(fā)者要求極高的語言，并不適合一個(gè)以產(chǎn)品為核心、需要快速成長(zhǎng)的團(tuán)隊(duì)。
我們現(xiàn)在用什么？我們?nèi)匀挥?Go 來支撐 90% 的服務(wù)。
Go 沒那么性感，但它足夠快、足夠安全，最重要的是——團(tuán)隊(duì)好擴(kuò)展。
我們會(huì)想念 Rust 的精致嗎？偶爾會(huì)。但我們后悔封殺它嗎？不后悔。
四、Rust雖好，警惕用力過猛
Rust 是一把好工具——如果你擁有合適的團(tuán)隊(duì)、合適的時(shí)間、和合適的問題。
但可惜我們，沒有這樣的團(tuán)隊(duì)、時(shí)間和問題場(chǎng)景。這就是我們 CTO 在一次重寫后封殺 Rust 的原因。
讀者中有類似經(jīng)歷的朋友對(duì)于文中“封殺 Rust ”的做法表示反對(duì)，表示這種做法其實(shí)是缺少遠(yuǎn)見的表現(xiàn)：
“你們遇到的問題，其實(shí)很多源于缺乏前瞻性規(guī)劃。Rust 的確更燒腦，但到了 Go 撐不住的復(fù)雜場(chǎng)景，它一樣也會(huì)變難。我兩個(gè)語言都寫，最終還是反復(fù)回到 Rust——現(xiàn)在連原型都用它寫。Go 的目標(biāo)很清楚，就是‘趕快上線’，但這不意味著它比 Rust 更優(yōu)。語言本身沒對(duì)錯(cuò)，關(guān)鍵在于團(tuán)隊(duì)的戰(zhàn)略選擇和工程成熟度。”
因此，這里值得一提的是，并不是所有團(tuán)隊(duì)都認(rèn)為 Rust 不適合生產(chǎn)環(huán)境。另一位讀者則指出，很多“Rust 重寫失敗”的根源，其實(shí)是開發(fā)者在熟悉 Rust 之后用力過猛，過于追求極致性能，從而引入了不必要的復(fù)雜生命周期結(jié)構(gòu)。
而如果團(tuán)隊(duì)在重寫時(shí)注意保持設(shè)計(jì)簡(jiǎn)潔、避免炫技，Rust 其實(shí)是可以很好落地的。
正如這位讀者所總結(jié)的：“保持簡(jiǎn)單，過程會(huì)順得多。在我參與的幾個(gè)大項(xiàng)目里，雖然起步難，但回頭看是值得的。”
參考鏈接：https://medium.com/@vardhanharsh8428/why-our-cto-banned-rust-after-one-rewrite-f415d2358fe6
