不要再說 Rust 過度炒作了

作者 | thenewwazoo（網名）

譯者 | 核子可樂，劉燕

策劃 | 劉燕

一位 Rust 支持者的心聲：Rust 真的沒有過度炒作

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

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

每當出現關於 Rust 的討論，最終大抵都要以 “炒作” 問題結束。

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

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

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

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

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

後來的故事大家都知道了，Java 不負衆望、宰治了整個軟件行業長達 20 年。接下來纔是重點，咱們聊聊爲什麼沒必要對 “炒作” 抱有過度惡意。

爲什麼總有炒作的聲音？

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

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

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

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

直到 Rust 出現之後，大家才意識到，出現了一種能解決所有問題的技術，這意味着編程時代開始由問題與解決方案的多對多關係、真正走向多對一的統籌處理階段。

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

“別再騙自己了”

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

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

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

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

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

別搞 “網絡糾察隊”

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

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

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

別在抱怨中錯失良機

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

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

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

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

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

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

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

寫在最後

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

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

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

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

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

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

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

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

• 我針對的不是各位讀者，只是一種現象。對事不對人。

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

• 除開 Rust，我也見過其他不少優秀的技術方案。

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

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

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

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

• 如果能用好垃圾技術真有成長空間，就意味着市面上必須不斷湧現更多垃圾技術…… 也許會，可我覺得但願不會。

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

• 我說自己的 Rust 編程速度跟 Python 開發相當，這可能是因爲我的 Python 編程速度本就不咋的。

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

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

原文鏈接：

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/tOwENn3GaMVkSXgqHxd34g