Linux Kernel 不再把 Rust 當實驗性：Tokio 維護者 Alice Ryhl 拆解這語言為什麼讓人上癮
TL;DR
- Rust 在 Tiobi index 上已經悄悄超過 PHP 跟 Go，2026 年是它真正進入主流的轉折點
- 「編譯通過就會跑」不是行銷話術，是語言設計團隊把幾十年來別人踩過的坑全部用編譯器堵起來的結果
- 文件範例會自動跑成測試、match 漏掉一個 case 直接編譯失敗、null 從根上就不存在
- Memory safety（記憶體安全）的意義比「程式不會 crash」大得多，它把整個 C/C++ 世界的資安漏洞家族整個砍掉
- 借用檢查器（borrow checker）讓你打架的時候，問題九成在你的資料結構，不在你的程式碼
- 沒有 BDFL（仁慈獨裁者），靠團隊投票跟 RFC 流程做決策，Edition 機制讓舊程式碼可以永遠跑下去
- Linux Kernel 在 2025 年底正式把 Rust 從「實驗性」標籤拿掉，跟 C 同等地位
- AI Coding 跟 Rust 的搭配可能比想像中合理：編譯器會告訴 agent 哪裡寫錯了
Podcast 跟來賓背景
這集在 2026 年 5 月 20 日播出的 The Pragmatic Engineer 是 Gergely Orosz 主持的軟體工程 podcast，他是前 Uber engineering manager，後來離開大公司做了同名的技術 newsletter，是 Substack 上排名第一的技術出版品，深度訪談一線工程師跟技術領導者。這集邀請 Alice Ryhl，她是 Google Android Rust 團隊的軟體工程師，目前主力在 Rust for Linux 這個專案，同時是 Tokio 的核心維護者之一，也是 Rust 語言團隊的顧問。Tokio 是 Rust 世界的 async runtime（非同步執行環境），你可以把它想成 Rust 後端的「標準函式庫」，全球大部分用 Rust 寫後端的公司都跑在它上面。Alice 沒有靠投履歷進 Google，她是十幾歲還在念書時就在 Rust Users Forum 上回了上萬篇問題，順便修文件，然後就被收編了。
「編譯通過就會跑」這句話為什麼重要
Alice 講的第一個重點，是 Rust 給人一種「程式編譯過了，大概就會動」的感覺。她自己也說這要加引號，bug 還是會有，但這種踏實感在其他語言裡其實很少見。
她拿 Java 的 null 來舉例。發明 null 的 Tony Hoare 自己後來公開承認這是他十億美金的錯誤。每次你呼叫一個函數，就可能踩到 null 然後整個崩掉。Rust 從一開始就決定不要這個東西，要表達「可能沒有值」必須明寫成 Option<T>，而且編譯器會逼你檢查，你裝不了沒看到。
放大到整個語言設計，會看到一個很清楚的哲學：別人寫了三十年程式踩過的所有坑，他們都試圖用編譯器擋下來。
舉幾個我看完訪談覺得最聰明的設計：
錯誤處理用值不用例外。 Rust 不丟 exception，函數會回傳 Result<T, E>，你想往上拋就在尾巴加一個問號 ?。忘記加？編譯失敗。意思就是你不可能不小心讓一個錯誤偷偷穿過去。
文件範例會自動跑成測試。 三條斜線開頭的註解就是文件，裡面寫的 code 範例會被當成 unit test 來跑。如果你改了底下的實作沒同步更新範例，編譯就掛掉。我寫了十幾年程式，看過無數次「文件跟程式碼對不上」的悲劇，這是第一次看到有語言把這件事用工具強制解掉。
Match 沒有窮舉就編譯失敗。 對一個 enum 做 switch（Rust 叫 match），少寫一個 case 編譯器就會炸。之後在 enum 加新狀態，整個 codebase 該補的地方它會告訴你在哪一行。
對寫過大型 codebase 的人來說，這套設計直接解決了一個老問題：refactor 之後到底有沒有改完？Alice 形容她重構的方式就是「跟著編譯器錯誤一路修，等它不再叫我就修完了」。
Memory Safety：把一整類資安漏洞從根上拔掉
從 TypeScript 轉 Rust 的賣點是穩定。從 C++ 轉 Rust 的賣點層次完全不一樣，是資安。
C++ 寫錯一個 array index、用過已經釋放的記憶體、寫入別人的 buffer，這些不只是會 crash 而已，每一個都是潛在的 CVE。攻擊者可以利用這種 bug 寫進精心構造的資料，最後可能讓自己變成 root。Alice 講了一個經典例子：很多攻擊就是讓某個物件被釋放後重複使用，然後在那塊記憶體位置塞一個 zero。如果那個位置剛好是 user ID，零就代表 root。整個系統就被吃了。
Rust 的 memory safety 保證的就是「不管你寫得多笨，這一類 bug 不會發生」。這不是讓你少寫一行 if，是把過去三十年 C/C++ 世界裡七成以上的 critical vulnerability 從根上拔掉。美國國防部、英國政府、各國資安單位這幾年都陸續發了文件，要求新專案不能再用沒有 memory safety 的語言。這是行政命令層級的事，不是技術愛好者的偏好。
借用檢查器打不過？問題八成在你的資料結構
Borrow checker 是 Rust 新手最常抱怨的東西，論壇上有個梗叫「fighting the borrow checker」。Alice 的觀察很犀利：大部分人在打架是因為他們在改錯地方。
她舉了一個例子：你想做一個 book 跟 page 的物件，book 裡有一堆 page，每個 page 又指回 book，TypeScript 寫起來毫無問題，Rust 寫起來就會卡住。原因是 Rust 預設不讓你做有迴圈的物件圖。
新手會卡住，是因為他們一直在改函數內的程式碼。其實該改的是 struct 本身，要嘛把它設計成 tree、DAG 這種無環結構，要嘛改用 reference counting 指標 Arc 來分享所有權。語法只是表象，Rust 在逼你把資料結構想清楚。
這個觀察對寫任何語言的工程師都有用。很多時候你會覺得「這個 bug 怎麼這麼難修」，問題往往不在這行 code，而在你最早設計的 schema 或物件關係。Rust 只是把這件事提前到編譯期讓你不得不面對。
治理：沒有 BDFL，靠 RFC 跟 Edition 撐起來
Python 有 Guido、Linux 有 Linus、Ruby 有 Matz，這些語言或專案都有所謂的仁慈獨裁者。Rust 沒有。
Alice 解釋了他們的決策模式：所有大決定都要經過 RFC（Request For Comment）流程。提案人寫一份文件，第一段必須是動機，接著要寫兩個版本的功能解釋，一個用「教學文件」的角度寫，一個用「語言規格書」的角度寫。光是這個雙視角寫作要求，就把很多「我覺得這個功能很酷」的提案逼著回去想清楚到底有沒有人會用。
決策方法叫 Final Comment Period（FCP）：團隊成員一個個打勾，當還剩兩個沒打勾的時候，開始倒數兩週的公開意見期，期間任何一個成員可以提 concern 把流程暫停。這個設計很細膩，意思是「不能讓動作快的人逼動作慢的人來不及看」。
另一個有意思的設計是 Edition。Rust 大概每三年發一個 edition（2015、2018、2021、2024），edition 跟 version 不一樣，是允許做「破壞性語法變更」但不會破壞舊 code 的機制。我寫 2021 edition 的 library，你寫 2024 edition 的 binary，可以混用沒問題。Python 2 升 Python 3 那種地獄式遷移在 Rust 設計上根本不會發生。
對長期維護 codebase 的人來說，這是很大的承諾。你今天寫的 Rust，理論上五年後新版的編譯器還是會幫你編譯。
Linux Kernel 把 Rust 從「實驗性」拿掉了
這是訪談裡最有產業意義的一條新聞。2025 年 12 月的 Linux Plumbers 維護者大會上，Linux 社群正式同意 Rust 不再是 experimental，跟 C 平起平坐。
對 Linux 這種有三十多年歷史、由 Linus Torvalds 親自審 patch 的專案來說，這幾乎是核子等級的決定。前幾年 Rust for Linux 還引發過 mailing list 上的公開論戰，現在大局已定。Alice 自己參與了好幾年的 Linux Plumbers，她說每年去一次，每年都覺得「天，跟去年完全不一樣了」。
順帶一提，Linus 對 Rust 的套件管理工具 Cargo 還是有意見。Alice 第一次見到 Linus 的時候，他直接走過來說他不喜歡 Cargo，因為 Cargo 會從網路上抓 code 下來執行，而他只信任他自己 Linux distribution 的 package manager。這種堅持很 Linus，但也提醒了一件事：套件生態系的供應鏈攻擊在 Rust 世界遲早會發生，NPM 那套劇本可能會重演，之前在 Anthropic 的 Mythos 與供應鏈攻擊那篇寫過 Vercel 跟 Roblox 那次事故，這條風險線在 Rust 上其實也是埋著的。
Rust 跟 AI Coding 的搭配可能比你想的合理
訪談最後聊到 AI。Alice 自己有用 Gemini CLI 寫過 patch，她的觀察是 Rust 跟 AI agent 的搭配有一個其他語言沒有的優勢：編譯器會給 agent 非常明確的 feedback。
寫過 Claude Code 或 Codex 的人應該都有經驗，AI 寫 Python 或 JS 的時候很常「跑起來像對的，但其實邏輯錯了」，因為這些語言給編譯器的限制太鬆。Rust 不一樣，type system、borrow checker、match 窮舉，這些都是 agent 可以拿來自我校正的訊號。Agent 寫錯了，編譯器直接把錯誤丟回去，它就有機會修。
Linux 社群也在做類似實驗。最近的 maintainer summit 上有人架了 bot，自動把 mailing list 的 patch 丟給 AI agent 做 code review，連 Linus 自己都說審查品質意外地不錯。這不是要取代人類審查，是多一層 safety net。對寫 kernel 這種失誤就是 CVE 的場景，多一層永遠不嫌少。
我覺得這條線值得追蹤。之前寫過 Coding Agent 不會感到痛，但你會、也聊過 前 OpenAI 工程師的 Coding Agent 使用心法，當時都在講 context engineering 的重要性。Rust 在這件事上有結構性優勢，它的 context 比較難讓 agent 自己騙自己。
給工程師的實際建議
Alice 對想學 Rust 的人有幾個建議：
第一，從官方的 Rust Book（線上免費）開始，這本被公認是最好的入門。
第二，學語言一定要有一個專案。找一個你想做的東西，比如一個 API server、一個 CLI 工具，用 Rust 把它寫出來，比看十本書都有效。
第三，AI 可以幫你產 Rust code，但有個陷阱：你會「看起來會了」但其實沒搞懂為什麼編譯器要那樣管你。她舉了個例子，她用 AI 改 Linux kernel 的 Makefile，AI 加了 Rust 的編譯 flag，但對 C 那邊原本就有的幾個 flag 沒處理，因為它不知道那些 flag 「為什麼存在」。Rust 很多設計的「為什麼」必須自己撞牆撞出來，這部分 AI 暫時取代不了。
收尾
聽完這集，我對 Rust 的印象從「聽說很酷但學習曲線陡」變成「這是少數認真在解決軟體業老問題的語言」。它的設計初衷擺在那裡：阻止工程師犯錯，比讓工程師開心更重要。這兩件事在感受上很不一樣。
我自己沒有要立刻去學 Rust 寫 production 的打算，但訪談裡有個觀察讓我留意：Rust 在 AI Coding 時代可能反而會被低估，因為大家會說「都有 AI 了，誰還在乎編譯器嚴不嚴」。實際情況可能反過來，AI 越強，編譯器越嚴的語言反而越能放心讓 agent 跑。這條線值得追蹤。
如果你對 AI Coding 跟程式語言生態的交叉地帶有興趣，我會持續在 wilsonhuang.xyz 寫這類觀察，歡迎訂閱不錯過。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件