RustWeek 2026 把 Rust 變成能交付的碼

RustWeek 2026 的重點不是宣傳，是 Rust 在 kernel、工具、嵌入式與圖形真的開始交付。

我追 Rust 追了好幾年，老實說，前幾年的感覺一直有點卡。每次看 conference talk，都像在聽同一套熟悉的劇本：更安全、更好寫、更適合系統程式，然後就沒了。聽起來都對，但我心裡還是會冒出那句老問題：所以呢？能不能真的進 production？能不能不要每次都停在「很有潛力」？我不是不信 Rust，我是不信這些漂亮說法最後有沒有落地。

直到我看到 Rust Bytes 的 RustWeek 2026 recap，那個味道才真的變了。這篇不是在吹一個語言多潮，而是在講一群人已經把 Rust 拿去碰 kernel、GPU driver、embedded、Cargo、gRPC、election software。這種內容很煩，因為它逼你承認一件事：Rust 現在不是在證明自己很會講道理，它是在證明自己能交作業。

這場會議不再像 demo reel

“RustWeek 2026 felt less like ‘Look what Rust could do’ and more like ‘Here’s what we’re already shipping.’”

這句我很買單。翻譯一下就是，RustWeek 2026 的重心已經從「看我們能做什麼」移到「看我們現在就在做什麼」。這不是文字遊戲，這是成熟度的差別。前者是社群在展示想像力，後者是社群在處理成本、風險、部署、維護，還有那些沒人想碰但每天都要碰的瑣事。

我自己看技術社群很久了，這種轉折通常不會太戲劇化。先是早期採用者在玩，接著是滿場的漂亮簡報，然後大家開始問同一個問題：你這東西能不能在真的環境裡活下來？RustWeek 2026 的訊號很清楚，它已經走到最後那段，而且不是靠口號，是靠一堆實際案例把你逼到牆角。

recap 裡提到 Utrecht 現場有超過 900 位 Rustaceans，還有 workshops、multi-track talks、hackathon、unconference、Rust Project All-Hands。這種組合很重要，因為它不像單純的行銷活動。它比較像一個工作現場：維護者、使用者、貢獻者、規格討論的人全部同桌。這才是我會信的訊號。

實操上我會怎麼看？我不再問「社群看起來活不活躍」，我會問「維護者、使用者、上游 contributor 有沒有在同一個地方一起解問題」。如果有，這個生態系通常比較不會空轉。RustWeek 看起來就是這種場子。

• 先看 talk 有沒有在講部署、維運、遷移，而不是只有語言新功能。
• 維護者有沒有出現，而且願不願意被問難題。
• 會議內容有沒有回流到 roadmap，而不是只留下拍照和讚嘆。

kernel 這條線，現在不是幻想

recap 裡點到 Greg Kroah-Hartman 的出現，還有 Rust-for-Linux 的討論，甚至提到 Rust 可能消掉大約 80% 的 kernel CVEs。這數字我不會當成神諭，但它夠大，夠刺眼，夠讓人認真看。因為 kernel bug 不是一般 bug，這種東西通常不是讓你 UI 壞掉而已，是安全事件、patch churn、pager duty、還有一堆人半夜被叫醒。

翻譯一下就是，Rust 的 safety model 已經被拉到最難的地方驗貨了。只要你能在 kernel 這種地方少掉一大塊 memory safety 的坑，討論就不再是哲學辯論，而是成本計算。這跟我以前在專案裡看團隊修 memory bug 很像：最煩的不是修掉那個 bug，是你知道下一個還會來，而且來的方式差不多。這種循環才是真正的成本。

我以前也看過一些團隊把「我們要用 Rust」講得像信仰宣言，結果實際上沒有對應到任何痛點。這樣很容易翻車。kernel 這條線之所以有說服力，是因為它直接對準大家都懂的問題：記憶體毀損、undefined behavior、維護壓力、審查負擔。不是抽象的「更好」，而是很現實的「少出事」。

實操寫法很簡單：如果你要在 critical codebase 引入 Rust，不要先講語言美學。先講你要砍掉哪一種事故、哪一種 review burden、哪一種 patch churn。然後先挑一個最貴的 subsystem，別一開始就想整包重寫。那種做法通常會把團隊拖死。

• 先選 failure 成本最高、歷史最臭的一段 code。
• 用 defect rate、incident rate、review time 來衡量，不要只看大家喜不喜歡。
• 把 maintainer 拉進設計，不要等 rewrite 變成宗教戰爭。

embedded 和 graphics 才是 Rust 真正落地的地方

我覺得這篇 recap 最有料的地方之一，就是 embedded 和 graphics。像 Espressif 的 esp-hal 1.1 讓 Rust 跑在 ESP32 chips 上更順，Tyr 團隊 也展示了開源的 Rust Mali GPU driver。這不是 trivia，這是 Rust 開始進到那種每個 byte、每個 unsafe boundary、每個 portability decision 都會咬你的地方。

也就是說，Rust 不再只是 backend service 或 CLI 工具的語言。它開始變成 hardware-adjacent 工作裡一個真的可以考慮的選項。以前大家遇到這種場景，常常就是嘆氣一句「那就只好寫 C 了」。這句話我聽太多次了，聽到後來只覺得疲乏，因為那通常代表你要接受一堆歷史包袱。

我自己碰過那種把硬體層當成神聖垃圾場的 codebase。沒人敢動，因為一動就炸；但不動又永遠累積技術債。最後就是 tribal knowledge、脆弱抽象、release 前大家靠咖啡和恐懼撐著。Rust 的價值在這裡，不是因為它讓硬體變善良，而是它讓你有機會把 guardrails 建起來。

實操上我會這樣做：先把最髒的 boundary 包起來，別急著重寫整個 stack。Rust 放在 invariant 最重要、C 最常咬人的地方，效果通常最好。尤其是 testing 很難、失敗代價很高的區塊，Rust 的價值會比你想像中明顯。

• 先包硬體邊界，不要先碰整個應用層。
• 把 unsafe surface area 壓到最小，並且固定 review。
• Rust 用在測試難、出錯貴的地方，最划算。

工具鏈變無聊，是好事

recap 裡也提到 compiler、async patterns、tooling improvements 這些平常看起來很乾的東西，還有 April 2026 goals update 裡的 faster compilation、trait system progress、Cargo improvements、Rust-for-Linux work。這些字眼很容易被滑過去，但如果你真的在大專案裡用過 Rust，就知道這些才是每天會碰到的痛點。

翻譯一下就是，Rust 正在變得沒那麼戲劇化。這聽起來很普通，但其實很重要。編譯變快，不是炫技，是你到底願不願意讓團隊每天都用這個語言。Cargo 變好，不是小修小補，是你 package 管理會不會搞到大家心累。trait system 進展也不是學術榮耀，是 compiler 能不能跟上人類的寫法。

我待過那種「語言大家都愛，但實際上每次改一行都像在等咖啡滴完」的團隊。那種體驗很傷。工具鏈如果不夠順，語言再漂亮都會被嫌到爆。Rust 現在最值得注意的地方，就是它開始把這些日常摩擦當成正經事處理，而不是只拿去做 keynote 的背景板。

實操寫法：你在選 stack 的時候，不要把 language features 跟 toolchain quality 分開看。直接量 build time、dependency pain、editor integration、release friction。這些東西爛，語言再優雅也救不了。Rust 現在的方向，至少有把這件事當回事。

Rust 開始進到有錢也有風險的地方

recap 提到 Abacus 用 Rust 重寫 election software、Bevy 參與一個 25 年老的 Java rendering engine 現代化、AWS 開源了用 Rust 寫的 ExtendDB，還有 gRPC 正式採用 Tonic，準備走 production-ready Rust gRPC crate。這些案例放一起看，壓力其實很一致：Rust 正在進到 correctness、portability、maintainability 直接影響商業結果的地方。

也就是說，這些不是玩具專案。選舉軟體不是玩具，25 年歷史的 rendering engine 不是玩具，DynamoDB-compatible adapter 也不是玩具。這些系統會逼你面對最現實的問題：你選的抽象能不能撐住現場，你的維護成本會不會越拖越大，你的 migration path 是不是只存在簡報裡。

我很喜歡這一段，因為它直接把語言戰爭那套廢話打掉。沒人會因為無聊去重寫 mission-critical system。會動手，通常是因為舊 stack 太貴、太難維護、太難守住安全線。Rust 會一直被拿來談，不是因為它時髦，而是因為它真的能減少系統失敗的方式。

實操上，如果你要在公司內部推 Rust，我會建議你只用三個論點：安全、長期維護、互通性。不要想一次把整家公司說服。你只需要一個 project 先證明 economics。真的，先證明值得，再談擴大。這樣比較不會被人當成語言教主。

• 安全敏感系統，Rust 的說服力最強。
• 壽命長的 codebase，最怕記憶體 bug 和維護失控。
• 互通性重的專案，Tonic 這類標準路徑很有用。

社群本身就是 Rust 的秘密武器

recap 花了不少篇幅講 Project All-Hands，也講到維護者、貢獻者、新手一起在場。這種內容看起來很軟，跟 kernel CVE 或 compiler work 比起來好像沒那麼硬，但我反而覺得這是最關鍵的訊號。工具會決定你能不能做事，社群會決定工具能不能活下去。

翻譯一下就是，Rust 不只是有好 compiler、好 docs 的語言，它還有一套足夠穩的共同工作方式，不會很快碎成一堆互相打架的小圈圈。這件事超難。很多技術社群都很會開戰，卻不太會收斂。最後不是 roadmap 變成私人日記，就是新人永遠找不到入口。

我看過太多 project 因為維護者消失、新人被冷處理、社群只剩互相吐槽而慢慢爛掉。Rust 的 conference 結構看起來比較像刻意避免這種事：正式議程、非正式討論、All-Hands、hackathon 全都混在一起。這不是裝熱鬧，這是在維持一個能持續演化的系統。

實操寫法：如果你在做 internal platform 或 framework，別只抄 code，連社群結構一起抄。讓使用者能直接跟維護者對話，讓 feedback 可以回到 roadmap，讓新貢獻者找得到入口。這不是裝樣子，這是讓技術系統不要死掉的方法。

我現在對 Rust 的感覺就是這樣：它不是已經把所有問題解掉，而是它周圍的人知道哪些問題重要，然後真的願意一直回來處理。這種東西，比任何漂亮 slogan 都有用。

可抄的模板

# Rust adoption memo template for a real team

## What changed
- We stopped treating Rust as a side experiment and started using it in production paths.
- We picked one boundary where bugs are expensive and rewrote that first.
- We measured build time, defect rate, and maintenance load instead of arguing from taste.

## Why this matters
- Memory safety reduced the class of issues we kept paying for twice.
- The toolchain was good enough for daily use, not just demos.
- The ecosystem had the libraries and standards we needed to fit existing infrastructure.

## Where to use Rust first
- Kernel-adjacent or systems-critical components
- Embedded or hardware-facing code
- Tooling, adapters, and integration layers
- Performance-sensitive services with long maintenance horizons

## Migration rules
1. Start at the highest-risk boundary, not the whole app.
2. Keep unsafe code isolated and reviewed.
3. Prefer interoperability over rewrites.
4. Track compile times and developer friction from day one.
5. Use Rust where failures are costly, not where it is fashionable.

## Decision checklist
- Does this code own memory or interact with untrusted input?
- Are bugs here expensive to diagnose or patch?
- Do we need a standard protocol or adapter path?
- Can we keep the Rust surface area small at first?
- Do we have maintainers who will stay with the code?

## Internal pitch
Rust is worth it here because it lowers the cost of correctness in a part of the system we keep revisiting.
We are not rewriting everything.
We are replacing the pieces where safety, maintainability, and long-term cost matter most.

## Adoption metrics
- Compile time before and after
- Number of memory-related incidents
- Review time for unsafe or boundary code
- Time to onboard a new engineer
- Maintenance effort per release

如果我真的要在團隊裡推 Rust，我會先丟這份 memo。它不會讓人立刻愛上 Rust，但至少會把討論拉回風險、成本、遷移方式，而不是「我覺得這語言很帥」。那種討論方式通常才是專案開始歪掉的地方。

來源致謝：這篇是根據 Rust Bytes 的 RustWeek 2026 Recap 與文中提到的專案延伸整理，我加了自己的拆解和實務寫法。像 esp-hal、Tonic、gRPC、ExtendDB 這些連結，都是從原始脈絡衍生出來的參考點。