不要再說 Rust 過度炒作了

作者 ｜ thenewwazoo （網名）

譯者 ｜ 核子可樂、劉燕

作者心聲：這篇文章我寫得可是小心翼翼，盡量避免任何過于肯定或者容易引起誤解的表述。我也有自己的正常工作、沒辦法真正全身心投入到 Rust 的宣傳工作，所以只能用這樣一篇文章表達自己的感受。篇幅有限，文章內容肯定無法面面俱到，所以我把自己想到但沒能討論的部分都列在了文末。

Rust 過度炒作？不至于不至于

每當出現(xiàn)關于 Rust 的討論，最終大抵都要以“炒作”問題結束。

很多朋友覺得 Rust 在網上水軍太多，每天都會聽到“Rust 最棒”、“人家 Rust 如何如何”、“Rust yyds”之類的言論。這幫家伙就不能消停一會？

確實，Rust 在網上熱度很高，但大家還記得當初 Java 剛興起時的情況嗎？如果不記得，恐怕是因為各位還很年輕。

那時候市面上充斥著滿是廢話的商貿雜志，而且神奇的是，他們都愛報道計算機方面的內容。于是我們就會看到一系列關于 Java 語言、發(fā)展前景以及它能解決的問題等文章。

那時候的互聯(lián)網還不像現(xiàn)在這樣充斥著很多極端情緒和“復讀”習慣，所以倒沒有醞釀出激烈的爭論，但人們的煩躁之情是共通的。

Java 語言那時候還沒有得到實踐檢驗，這種未經證實的技術報道太多了——沒人用過、沒人了解、沒人在乎。畢竟虛擬機運行時之前就有，C 和 COBOL 也都非常成熟了，為什么非得拿 Java 來硬湊熱點？

后來的故事大家都知道了，Java 不負眾望、宰治了整個軟件行業(yè)長達 20 年。接下來才是重點，咱們聊聊為什么沒必要對“炒作”抱有過度惡意。

為什么總有炒作之聲？

在 Rust 出現(xiàn)之前，我們沒有必要反復強調某些問題，因為根本就沒有真正的解決方案。每個人都知道緩沖區(qū)溢出是個大麻煩，而 Java 等語言可以解決問題；大家都清楚自主編寫的數(shù)據(jù)結構缺陷多多，但 Python 等語言在這方面能出把力。

所以那時候的人們還不會以某一大類問題（例如「組合便捷性」和「內存安全性」）為切入點討論痛點。畢竟既然不打算重新設計一種能解決問題的編程語言，談得這么寬泛完全是在浪費時間。

唯一稱得上共通難題的就只有安全性問題，但之前的解決思路要么是在性能與可維護性之間進行權衡（Python、Ruby、Erlang），要么就是維持在可接受的水平上然后棄之不理（Java、JavaScript、PHP）。

這些問題、甚至是整個問題類別，都成了程序領域中的“背景輻射”。每個人都知道有這些問題、每個人偶爾都會抱怨，但就是沒有解決的辦法。

直到 Rust 出現(xiàn)之后，大家才意識到，出現(xiàn)了一種能解決所有問題的技術，這意味著編程時代開始由問題與解決方案的多對多關系、真正走向多對一的統(tǒng)籌處理階段。

于是我們在網上的討論中逐漸開始從當前問題出發(fā)總結問題大類，甚至還要把解決思路拓寬到其他問題大類當中！這本應是個巨大的優(yōu)勢，但正是這種優(yōu)勢讓 Rust 顯得似乎一夜之間就無處不在，而且跟我們日常工作中的各個環(huán)節(jié)都息息相關。

“別再騙自己了”

作為技術人員和工程師的核心特征，大家應該很擅長冷靜客觀地評估系統(tǒng)。你可以先把“炒作”這碼事放在一邊，專門根據(jù)實際表現(xiàn)考量解決方案。決定判斷的應該是事實、而非情緒，對吧？一旦因為“炒作”而抵制 Rust，那我們就離討論的基本訴求越來越遠了。更不用說極端的人身攻擊了，那是小孩子打架般的玩意，不值一駁。

我之所以堅持認為“Rust 炒作論”是種有害的侮辱性言論，并不是因為我從 Rust 基金會那拿了錢，或者是想勸說大家購買 Rust Enterprise。

坦白地講，我在編程行業(yè)待了 30 年，體會過用沒有 type 安全設計的語言進行大規(guī)模重構，用會產生 GC 開銷的語言編寫快速服務，用缺乏良好內存清理機制的語言編寫緊湊代碼，再把這些成果運行在微型計算機以及后來的分布式多核心集群上。

這些我都干過，而且都成功了……但過程非常非常痛苦。所以當我看到 Rust 的一剎那，我就知道這是個好東西。

我之所以力推 Rust，是因為它真的很出色、沒準能幫助大家解決現(xiàn)實問題（包括很多你已經覺得無藥可救的問題）。這篇文章完全發(fā)自肺腑、出于真誠，我只談自己的切身感受與判斷；如果大家有不同意見，也請以同樣真誠的態(tài)度給出說明，感謝各位。

別搞“網絡糾察隊”

更重要的是，別搞什么“網絡糾察隊”。所謂針對 Rust“水軍”和“炒作”的抱怨其實就是一種網絡糾察行為，或者說是對人們的立場乃至表達方式做出的另一種抱怨。相信很多朋友也和我一樣，已經厭倦了這種毫無意義、既無成效也無建設性的反復爭論。

我寫這篇文章，是因為我自己有表達的沖動。各位覺得不喜歡可以自行離開，這很正常。但我絕對不會刻意去迎合某些人脆弱的神經，也不想順應那些在網上噴 Rust 噴到血壓上升的家伙的立場。

我的出發(fā)點非常單純：只要是能給編程行業(yè)帶來實質性改善的好東西、只要是能讓程序員日常工作更輕松的東西，我就支持。

別在抱怨中錯失良機

曾幾何時，Java 也卷起過一股“風潮”。但隨著“炒作”的消退，這種爭議也隨之瓦解。

總有人說“真正的”程序員絕不用 Java，我覺得 Rust 倒是沒有這個問題，因為它“夠難”（但其實并不難，至少沒大家想象的那么難）。

之所以沒人把 Java 視為威脅，是因為當時互聯(lián)網行業(yè)正在快速發(fā)展，眾多新崗位的涌現(xiàn)讓新語言成為單純的工具而非威脅。當時最大的分歧，就是很多人覺得 Java 難度低，“格局”不夠，用了它好像就跟普羅大眾距離拉近了一般，無法凸顯自己編程精英的高中地位。

但如今不同了，經濟形勢放緩，軟件開發(fā)行業(yè)也受到了波及，每個人都需要謹小慎微地規(guī)劃未來的前進道路。與其靠自己的腦袋記住一切陷阱，為什么不直接使用一種能消除這些陷阱的語言？誰把精力節(jié)約下來用在更有意義的地方，誰就能在殘酷的市場競爭中占據(jù)主動。

從企業(yè)的角度來看更是如何，Rust 能幫助大家省下代碼調試或重構方面的成本，規(guī)避安全演習開支，并通過近裸機運行方式省下硬件投入。

我現(xiàn)在的 Rust 編程速度已經不亞于 Python 了，相信大家也能做到。軟件的上市時間非常重要，而 Rust 與腳本語言之間的開發(fā)效率差距正在迅速縮小。如果繼續(xù)頑抗到底，那你的解決方案發(fā)布速度會變慢、啟動及維護的成本會更高，其他人就可能在你繼續(xù)抱怨的同時悄悄瓜分掉你的市場份額。

正因為 Rust 具有顯著的競爭優(yōu)勢、能夠編寫出超越其他語言的高質量代碼，所以招聘經理們才開始用 Rust 水平衡量頂尖人才的業(yè)務能力。在不久的未來，這種標準將成為新的常態(tài)，哪怕每天把 Rust 噴上一萬遍也改變不了這個現(xiàn)實。

寫在最后……

我知道，很多朋友會在評論區(qū)里糾正文章里的某些細節(jié)，這里我就自己列出來算了：

大獲成功的 Java 其實黑點也不少，一樣充滿了問題。

一切得慢慢來，操之過急只會把編程員工們嚇跑。

上世紀六十年代就有人提出過分類解決問題的想法，但無一例外都失敗了。

也許我這 30 年里寫過的代碼都很差勁，確實有這種可能。

水平夠高的程序員當然可以克服或規(guī)避其他語言中的固有缺陷。

語言不是萬能的，任何語言都有可能寫出糟糕的代碼，還是要看人。

語言不是萬能的，任何語言都有可能寫出不安全的代碼。

我針對的不是各位讀者，只是一種現(xiàn)象。對事不對人。

Rust 當然解決不了所有問題，這一點必須實事求是。

除開 Rust，我也見過其他不少優(yōu)秀的技術方案。

Rust 是門大語言，涉及的學習內容眾多，所以上手難度確實不低。

很難把 Rust 的改進效果量化出來。

Rust 中也有很多目前無法、甚至永遠無法解決的難點和問題。

能用好垃圾技術確實算是種特長，只是這特長沒什么成長空間。

如果能用好垃圾技術真有成長空間，就意味著市面上必須不斷涌現(xiàn)更多垃圾技術……也許會，可我覺得但愿不會。

可能 Rust 也是垃圾技術之一，只是我還沒意識到。

我說自己的 Rust 編程速度跟 Python 開發(fā)相當，這可能是因為我的 Python 編程速度本就不咋的。

畢竟還有自己的工作，所以非常抱歉，我只能在文章中做出概括性的論述，沒法結合具體問題詳盡介紹 Rust 的使用心得。

這篇文章本身也屬于抱怨，我承認～

https://thenewwazoo.github.io/whining.html

關鍵詞： 不要再說 Rust 過度炒作了 rust java