由於我關於 Rust 的專業寫作已經移至 corrode blog，我在這裡可以稍微輕鬆一點，分享一些我對近期在既有軟體中使用 Rust 的爭論的個人想法。

討論中的兩個專案是 git（kernel thread、Hacker News Discussion）以及最近用 Rust 重寫的 coreutils in Rust，它將隨 Ubuntu 25.10 Quizzical Quokka 一起發佈。

促使我寫這篇文章的是一場在 Twitter 上的討論，以及一篇標題為 “Are We Chasing Language Hype Over Solving Real Problems?（《我們是在追逐語言熱潮，而非解決實際問題嗎？》）” 的部落格文章。

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

回到我剛創立 corrode 的時候，大家總是說 Rust 沒有被用在任何嚴肅的專案上。我從客戶合作中得知許多在正式環境中的使用案例，但當時公開的資訊非常少。因此，我們開設了 ‘Rust in Production’ 播客，以證明企業確實會為了實際應用而選擇 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 的演講，他在演講中指出，他們的開機載入程式以及先占式多工作業系統 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 重寫是不可行的。好消息是，你可以逐步地、一次一個元件地用 Rust 重寫 C/C++ 程式碼。這正是 git 維護者們所規劃的——在新元件中使用 Rust。

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

即使你使用 Rust，你仍然可以用 GPL 或任何你想要的授權來授權你的程式碼。Git 本身仍然維持 GPL，許多 Rust 專案也使用各種不同的授權，而不僅是 MIT。對授權的恐懼，往往是由不了解開源授權運作方式的人所提出，或者可能只是 FUD。

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

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

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

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

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

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

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

這根本是在輕視那些在這些專案上耕耘數年甚至數十年的維護者們的專業技術，而他們比任何人都更了解其中的痛點。

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

「這是感染軟體的覺醒思想病毒的一部分」

想像一下，居然有人認為記憶體安全是一種政治陰謀。顯然，防止緩衝區溢位現在竟成了一種意識形態立場。與此最相關的大概就是白宮的技術報告，該報告建議政府軟體應使用記憶體安全的語言，並要求接受聯邦經費的軟體必須具備記憶體安全，這是一個相當合理的觀點。

結論

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

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

如果你有興趣進一步了解如何在正式環境中使用 Rust，歡迎參考 我的另一個部落格，或收聽 Rust in Production 播客。

哦，還有，如果你認識會發表這類言論的人，就別再爭辯了，直接把這篇文章的連結傳給他們吧。