Rust 2026 把 C++ 痛點變安全系統

Rust 的 2026 變化，讓它更像能直接上 production 的系統語言。

我用 Rust 有一陣子了。老實說，前幾年我每次想把它塞進真實專案，都有種先繳學費再談效率的感覺。編譯器很常是對的，這點我不否認；但問題是，我不是在跟編譯器比誰理性，我是在趕交付。lifetimes、async、型別推導，一個接一個把我卡在半路，團隊也常被我搞到懷疑人生。Rust 的承諾我懂，我不爽的是它常常用摩擦的方式把承諾送來。

後來我看到這篇 Dev|Journal on earezki.com 的整理，才覺得有點意思。它不是在吹 Rust 多潮，而是在講一件更實際的事：Rust 什麼時候開始不再像特技表演，而像正常的 production 選項。這種轉變，才是我真正想看的。

文中提到 Rust production usage 從 2023 的 28% 升到 2025 的 47%，也點名 Microsoft、Google、Amazon 這些大公司在用。這種數字我不會當聖旨，但它至少告訴我：Rust 不再只是少數人自嗨的工具。它開始進到那些不能亂玩的系統裡。學習滿意度從 42% 到 71% 這種變化，也很像是工具鏈和生態真的比較能用了，不然大家不會突然變得比較有耐心。

Rust 不再是身分標籤，而是能交差的工具

“Rust has crossed the chasm into mainstream production at Microsoft, Google, and Amazon.”

這句話翻成白話就是：Rust 不再只是拿來證明你很在乎 memory safety 的語言。它真的開始出現在不能亂來的地方。大公司把語言放進 production，不是為了形象，是因為它在成本、風險、長期維護上終於說得通了。

我自己以前也把 Rust 當成「之後再重寫」的候選人。現在比較常見的心態反而是：既然這個服務一開始就會碰到併發、穩定性、維護壓力，那乾脆直接用 Rust，別先把未來的坑挖好。這個差別很大。不是 Rust 突然變成輕鬆語言，而是它周圍的東西成熟了：套件、範例、團隊經驗、最佳實務，都比較像樣了。

我之前帶過一個小團隊做內部服務，當時如果要選 Rust，大家第一個反應不是「好啊」，而是「這會不會拖慢我們」。現在這個問題還是會有人問，但答案已經沒那麼偏向否定。因為當你真的碰到資料一致性、記憶體安全、網路服務穩定性，Rust 的優勢不是口號，是少掉一堆後患。

實操寫法很簡單：不要把 Rust 當成特殊專案。拿一個真的會痛的系統問題來評估，別拿玩具 demo。你可以挑一個有狀態、有併發、有故障成本的服務，直接跟現有 stack 用同一套成功標準比：維護性、事故率、上手時間。

• 適合 Rust 的地方：infra、auth、queue、parser、network service。
• 不適合硬塞的地方：已經用腳本語言就很順的工具。
• 比較時看營運成本，不要只看編譯器有多兇。

Memory safety 終於不是哲學辯論

這篇文章特別提到 Microsoft 的安全立場，說它 70% 的 CVEs 跟 memory safety 有關。這種數字很煩，因為它會直接把很多空談打掉。你如果真的修過 use-after-free、double free、buffer overflow，應該知道那不是語言潔癖，那是凌晨兩點的事故單。

Rust 的 borrow checker 一開始很像在找你麻煩，但只要你把它跟線上事故的代價放一起看，它就比較像一個超嚴格 reviewer。以前我也以為 borrow checker 主要是 developer experience 的問題，後來我比較願意把它看成 reliability feature，只是剛好長得像 compiler。

也就是說，Rust 現在吸引人的地方不只在工程師喜不喜歡，而是 security team 跟 platform team 終於能在同一張桌子上講話。這很少見。通常一邊要速度，一邊要保守，兩邊互看不順眼。Rust 至少提供一個共同理由：它能在設計階段就砍掉一批 memory bug。

我以前在 code review 裡看過太多「先上線再說」的記憶體處理，最後都變成 postmortem 的素材。這種東西在 C/C++ 世界很常見，不是因為大家笨，是因為語言本身容許你把錯誤留到很後面才爆。Rust 的價值就在這裡：它把很多錯誤提前攔下來，讓你不用拿 production 當測試場。

實操寫法：你要在公司內推 Rust，別先講品味。先講事故減少。把你們現有 stack 裡的 memory 相關問題列出來，對照哪些類型在 Rust 裡幾乎不會發生。真的要推動決策，postmortem 比語言哲學有用多了。

• 先盤點最近 6 到 12 個月的 memory 相關事故。
• 標出哪些是 Rust 幾乎可以直接避免的。
• 用這份清單決定是重寫、開新服務，還是只換某個模組。

Async Rust 終於不像在解魔術方塊

我最有感的變化之一，是 async Rust 比以前像樣太多。文章裡提到，現在的 async/await 體驗已經比早期那種手動 polling、Pin/Box 亂鬥好很多。這我完全有感。以前寫 async Rust，有時候真的像在跟一個很聰明但很不耐煩的系統打交道，功能很強，但每一步都在提醒你：你最好知道自己在幹嘛。

這件事重要，是因為 async 幾乎決定了系統語言能不能真的做網路服務、job processor、API gateway 這些實際工作。你如果不能用合理方式表達併發，最後就只能停在「適合系統人研究」的階段。現在 Rust 比較接近大家熟悉的 async/await 心智模型，像 Go 或 Python 那樣，至少不用每個人都先去修 runtime 工程課。

翻譯一下就是：Rust 不再逼每個開發者都變成 executor 專家。你可以寫 async code，但不用一直想 pinning、executor、ownership 怎麼互相打架。這不代表 async 變簡單，只是它終於少了很多不必要的儀式感。

我之前碰過一個內部服務，原本團隊想用 Rust 試試看，但卡在 async 寫法太分裂。有人用這個 runtime，有人用那個 crate，最後 codebase 長得像拼裝車。後來最痛的不是語法，而是每個人都在發明自己的併發習慣。這種狀況在 Rust 專案裡很常見，所以你一開始就要把路線定死。

實操寫法：如果你要用 Rust 做 service，async stack 先統一。runtime、web framework、DB layer 先選好，別讓每個工程師自己挑一套。你要的是穩定的開發節奏，不是語言實驗室。

我會優先看 Tokio、Axum、SQLx。這組合不是因為它們神奇，而是因為它們把 async 路徑收斂得夠清楚，團隊比較不會每天都在討論基礎設施哲學。

生態系成熟，才是 Rust 真正能落地的原因

文章說 crate ecosystem 已經到 critical mass。這句話我很買單，因為語言能不能用，最後常常不是看語法，而是看你有沒有現成的輪子。沒有好用的 routing、database、observability、auth library，我就得自己補齊一堆 plumbing，最後產品還沒做，底層先燒光。

Rust 現在比較舒服的地方，是它開始有明確的預設值。API 常見是 Axum，併發常見是 Tokio，資料庫常見是 SQLx。這種預設很重要，因為它減少團隊爭論。以前我看過不少團隊在 framework 選擇上吵一週，最後不是因為選項太多，而是因為沒人想接 weird edge cases。預設值越清楚，團隊越省力。

也就是說，Rust 變得更適合標準化了。這對 production 系統超重要。當 stack 有穩定慣例時，文件比較好寫、招人比較不怕、code review 也不會變成架構諮商。

我自己的做法是，Rust 專案一開始就先寫 house stack，別等到第一個 PR 才開始吵。你可以把 HTTP、DB、logging、config、testing 的選型先固定，讓大家知道什麼是預設，什麼是例外。

• 選一個 web framework，整個專案都用它。
• 選一個 async runtime，別再分裂。
• 選一個資料庫存取層，順便定 query style。

編譯時間不再是每天抱怨的來源

文章提到，中型專案的 incremental build 從 2024 的大約 35 秒降到 2026 的大約 8 秒。這不是小改善，這是從「我去泡杯咖啡」變成「我還能保持在狀態裡」的差別。開發節奏被編譯時間拖住，真的會改變人怎麼寫 code。

我一直覺得 compile time 是語言採用的隱形殺手。回饋慢，大家就不想 refactor；回饋慢，大家就不想做小實驗；回饋慢，大家就開始把改動包大包，因為每次 build 都像在付稅。最後 code quality 不是被某個大 bug 打爛，是被日常摩擦慢慢磨掉。

翻譯一下就是：Rust 現在在日常開發上沒那麼折磨人了。這件事很無聊，但很重要。因為真正用語言的人，不是每天在看 benchmark，是每天在改 code。只要 edit-compile-run 的迴圈夠順，大家才願意持續重構。

我以前也犯過錯，把 compile time 當成「反正是 systems language，忍一下就好」。結果團隊很快就開始避開小改動，所有東西都拖到一起送。後來我才懂，編譯速度不是舒適度而已，它會直接影響工程習慣。

實操寫法：如果你現在 Rust 專案還在抱怨編譯慢，別把它當性格問題。先開 incremental build，拆 crate 要有策略，熱路徑別塞太多泛型，CI 也要量 build time。你要讓團隊感受到回饋，不然他們只會繞開問題。

而且別忘了，所謂「嚴肅的系統」也還是人寫的。人如果每天都在等編譯，最後就會想辦法偷懶。工具鏈好不好，真的會決定團隊有沒有耐心把事情做好。

Rust 變好用，不代表你可以亂寫

文章說 learning satisfaction 從 42% 升到 71%，我相信這個方向是真的。只是我不覺得 Rust 突然變簡單了，而是它的路徑比較不刁鑽了。它還是要求紀律，還是看重 ownership，還是會懲罰亂來，但這跟「工具自己在找你麻煩」是兩回事。

也就是說，最好的導入方式不是硬把 Rust 寫成另一種 Python。你越想把它塞回舊習慣，它越會反咬你。第一版先小、先清楚、先把邊界寫乾淨，別一開始就搞自製 framework。Rust 很吃你有沒有尊重它的形狀。

我自己也踩過這個坑。最容易把 Rust 寫得很痛苦的方式，就是把動態語言的壞習慣整包搬過來，然後怪它太囉唆。後來我開始拆小模組、把邊界寫明、讓 compiler 幫我守規矩，整個體驗就順很多。

實操寫法：把 Rust 當成設計訓練，不只是語法訓練。新手要懂 ownership、borrowing、async boundary、error handling，這些不是語法細節，是架構思維。教對了，Rust 就不會一直像在修行。

可抄的模板

## Rust adoption checklist for a real team

### 1) Pick one problem worth the switch
- memory safety risk
- high-concurrency service
- parser or network gateway
- CPU-heavy component

### 2) Define success in operational terms
- fewer incidents
- acceptable onboarding time
- build time under a target
- clear ownership for the service

### 3) Standardize the stack early
- runtime: Tokio
- web framework: Axum
- database layer: SQLx
- serialization: serde
- middleware: tower-http

### 4) Set team rules before the first PR
- one async pattern
- one error-handling style
- one logging format
- one testing strategy

### 5) Start small on purpose
- build one service, not a platform rewrite
- keep the first module boring
- avoid custom abstractions until you have shipped once

### 6) Measure what actually matters
- incident count
- PR review time
- build time
- time to onboard a new engineer

### 7) Review after 30 days
- what felt easier than the old stack?
- where did Rust slow us down?
- which pain points were language, and which were team habits?
- should we expand Rust usage or stop here?

這段模板是我把原文的判斷，拆成可以直接拿去做團隊評估的版本。原始觀點來自來源文章，但這份 checklist、落地順序、以及怎麼拿去內部討論，是我自己的整理。

原始來源：https://earezki.com/ai-news/2026-05-23-rust-in-2026-the-systems-language-that-finally-became-approachable/。文中的採用率、學習滿意度、編譯時間與安全敘事是衍生自該文；上面這份導入模板與團隊寫法是我重新整理後的可用版本。