由於我關於 Rust 的專業寫作已經移至 corrode 部落格，在這裡我可以寫得輕鬆一點，分享一下我對最近圍繞在既有軟體中採用 Rust 的爭論的一些個人想法。

引起討論的兩個專案是 git（核心郵件串、Hacker News 討論）以及最近用 Rust 重寫的 coreutils，它將隨 Ubuntu 25.10 Quizzical Quokka 一同出貨。

促使我寫這篇文章的是一場在 Twitter 上的討論，以及一篇題為 「Are We Chasing Language Hype Over Solving Real Problems?」 的部落格文章。

在這兩個案例中，作者們都在揣測選擇 Rust 背後的動機，而作為一個協助團隊在生產環境中導入 Rust 的人，我只覺得這些看法……很好笑。

回想我剛創立 corrode 的時候，大家總說 Rust 沒被用在什麼正經的地方。透過客戶專案，我知道其實有不少生產環境的應用案例，但公開資訊卻很少。因此，我們開設了 「Rust in Production」 Podcast，想證明確實有公司在實際應用中選擇 Rust。不過，人們不喜歡被證明是錯的，於是那套陰謀論就演變成了「Big Rust」想稱霸世界的說法。😆

來看看那篇部落格文章和 Twitter 討論串中的一些說法，看看它們其實多容易被反駁。

「GNU Core Utils 在其存在的整個歷史中基本上從未出現過任何重大的安全性漏洞」

要真是如此就好了。只要做個快速 CVE 搜尋，就能看到數十年來出現過多起安全性問題，包括緩衝區溢位和路徑遍歷漏洞。就在幾個月前，還在 sort 中發現了一個堆積緩衝區讀取不足（heap buffer under-read）的問題，只要攻擊者送出特製的輸入串流，就可能導致敏感資料外洩。

GNU coreutils 是全球使用最廣泛的軟體套件之一，安裝量達數十億，有數百位（甚至數千位？）開發者在檢視程式碼。即便如此，漏洞還是會發生。不，寫出正確、安全的 C 程式碼並不容易。不，就算你格外小心、再怎麼自律也一樣不容易。

ls 就有五千行之多。（看看原始碼）。光是為了印出檔名和詮釋資料就要這麼多程式碼，攻擊面自然很大！

「Rust 再怎麼樣也只能追上 C 的效能，而且通常還比較慢」

Trifecta 的研究顯示，在某些情況下是有可能寫出比 C 更快的 Rust 程式碼的。尤其是在並行工作負載且同時提供記憶體安全保障的場景下。如果寫出安全的 C 程式碼已經很難了，不妨試試看寫出安全的並行 C 程式碼！

這正是 Rust 發光的地方。你可以在無需擔心安全性問題的情況下，達到驚人的平行化程度。而且，不，你不需要把程式碼塞滿 unsafe 區塊。看看 Steve Klabnik 最近關於 Oxide 的演講，他提到他們的 bootloader 和先占式多工作業系統 hubris——兩者都算是非常核心的系統程式碼——各自僅包含 5% 的 unsafe 程式碼。你甚至可以完全不用 unsafe 寫出龐大的 Rust 程式碼庫。

舉個簡單的例子，有一天我動手用 Rust 重寫了 cat，結果在我的機器上比 GNU cat 快了 3 倍。你可以在此閱讀那篇文章。我所做的只是用 splice 來複製資料，省去了一次記憶體複製。效能不只取決於語言，也取決於你使用的演算法和系統呼叫。

如果你能善用 Rust 的優勢，就能達到與 C 相當的效能。至少在技術上沒有什麼限制會阻礙你這麼做。而且我個人在用 Rust 時，更願意積極地最佳化程式碼，因為我不用擔心會因此引入記憶體安全方面的錯誤。看來有這種感覺的不只我一個。

「在這個產業裡，我們獎勵的是新奇而非必要」

這種說法忽略了一點：大多數成功的公司（Google、Meta 等）主要使用的是久經考驗的技術堆疊，而非最前緣的語言。這些公司擁有龐大的程式碼庫，根本無法負擔把所有東西都用最新流行的語言重寫。但他們看到了在新元件中使用 Rust、並逐步重寫既有元件的價值。那是因為70% 的安全性漏洞都是記憶體安全問題，而這些問題的修復成本極高。如果這些公司能不換語言就解決這個問題，他們早就這麼做了。

再說，Rust 也已經不算是新語言了。Rust 1.0 已經是 10 多年前發佈的！產業的步調雖然慢，但也沒慢到那種程度。你可能會很驚訝，有多少老牌公司早已在默默使用 Rust，卻從未大肆宣揚，也沒把它當成什麼「新奇玩意」。

「百分之百是策劃好的」

在那個 Twitter 討論串裡，好幾個人深信這是什麼協調好的宏大計畫，而非開發者自行選擇了更好的工具，然而 git 和 coreutils 的維護者們早已在公開論壇上開誠布公地討論過他們的動機，所有人都看得到。

「他們想取代／抹去 C。這不可能發生」

他們說得沒錯。C 不會那麼快消失。現實世界中到處都是 C/C++ 程式碼，要全部用 Rust 重寫並不可行。好消息是，你可以逐步、一次一個元件地把 C/C++ 程式碼用 Rust 重寫。這正是 git 維護者們的計畫——在新元件中使用 Rust。

「他們把採用 GNU 授權的軟體重寫成採用 MIT 授權的軟體」

即使你使用 Rust，你仍然可以把程式碼以 GPL 或任何你想要的授權釋出。Git 本身仍維持 GPL，許多 Rust 專案也採用各種不同的授權，並非只有 MIT。對授權的恐慌，往往是出自不了解開源授權如何運作的人，或者根本就是 FUD。

MIT 程式碼仍然與 GPL 程式碼相容，你可以在同一個專案中同時使用兩者而不會有問題。只不過最終的產物（也就是你交付給使用者的東西，例如二進位執行檔）會因為 GPL 的感染性而受到 GPL 的涵蓋。

「這只是開發者太無聊，想玩閃亮的新語言罷了」

年長的 C 專案維護者們逐漸退休，願意為了在閒暇時維護老舊程式碼而去學 C 的新進開發者也越來越少。C 開發者基本上正在逐漸凋零。新一代的開發者想使用現代語言，這又有什麼好責怪的呢？難道你會想去維護一個 40 年歷史的 COBOL 程式碼庫或古老的 Perl 腳本嗎？我們總得向前走。

「為什麼不乾脆打造全新的東西，而要重寫既有的工具？」

事情沒那麼簡單。程式碼只是故事的一部分。另一部分是生態系、工具鏈、整合、文件以及使用者群。這些都需要花上數年才能建立起來。使用者不想改變自己的工作流程，所以他們想要的是能直接替換的替代品。那些經過驗證的介面和 API，無論看起來多麼粗糙、過時，都具有很大的價值。

但話說回來，確實也有許多新工具正用 Rust 打造中。

「他們根本不懂如何真正解決問題，只會追逐潮流」

這種說法，完全否定了那些在這些專案上耕耘數年、甚至數十年的維護者們的專業能力——他們比任何人都更了解其中的痛點。

如果他們真的只是在追逐潮流，一開始就不會去維護這些專案了！這些人是世界上最有經驗的開發者之一，卻還有人想教他們該怎麼做好自己的工作。

「這是感染軟體界的覺醒病毒（woke mind virus）的一部分」

真難想像有人會把記憶體安全當成政治陰謀。看來防止緩衝區溢位現在竟成了一種意識形態立場。與此最接近的大概就是白宮的那份技術報告，它建議政府軟體應使用記憶體安全的語言，並要求接受聯邦經費的軟體必須具備記憶體安全性——這其實是相當合理的看法。

結論

我還可以繼續說下去，但我想你已經明白我的意思了。

真正給過 Rust 一次公平機會的人都知道，它在記憶體安全、並行處理與可維護性方面具有優勢。這不是在追逐炒作，而是對軟體品質的長期投資。隨著每天都有越來越多公司成功導入 Rust，它也越來越成為許多新專案的預設選擇。

如果你想進一步了解如何在生產環境中使用 Rust，歡迎看看我的另一個部落格，或收聽 Rust in Production Podcast。

喔對了，如果你認識會發表這類言論的人，別再跟他爭了，直接把這篇文章的連結傳給他吧。