Rust 讓你先跑分，Go 讓你先上線

以前我以為 Rust 贏效能就該全押，現在我只看延遲、記憶體、上線速度三件事。

我用 Rust 跟 Go 比了很久，久到一看到比較文就知道它想把我帶去哪裡。很多文章很愛把差異壓成一張表，然後假裝自己已經把事情講完了。問題是，真實系統根本不是這樣。Go 我也上過，服務好養、交付快，團隊不會每天跟編譯器吵架。Rust 我也踩過，CPU 很爽，團隊很痛，痛到兩個 sprint 都在補洞。

這次我看的是 Tech Insider 的 2026 Rust vs Go 比較。我先不管標題，先看它怎麼拆 tradeoff。它提到 Rust 1.83 把 async closures 穩住了，Go 1.23 把 generics、logging、觀測性補得更順，還提到 Rust 在安全敏感工作裡的需求在往上走。這些細節才真的會改變決策，不是那種喊口號的廢話。

307k vs 180k 這種數字，先別急著高潮

“A 2026 head-to-head video benchmark demonstrated that a Rust Axum application reached approximately 307,000 requests per second, compared to roughly 180,000 requests per second for the equivalent Go implementation.”

翻譯一下就是，Rust 在某些 CPU 密集、條件受控的場景下，確實可以把 Go 拉開一段距離。文章也提到 Rust 在某些比較裡大概比 Go 快 1.5 倍，像 JSON parsing、tree traversal、matrix work 這類工作，差距甚至更明顯。

但我看這種數字的第一反應永遠不是「哇好快」，而是「你的 workload 是什麼」。我在內部 perf review 看過太多次了：有人拿 throughput 數字去套一個 80% 時間都在等資料庫的服務，然後得出一個很自信的錯誤結論。那不是分析，那是自我感動。

我之前也做過類似的事。那時候我們在 Go API 上追 p99，結果發現瓶頸根本不是語言，是下游查詢和序列化。後來我們把熱路徑拆出來，才知道真正值得優化的是資料處理段，不是整個服務一起翻修。

實操寫法很簡單：先把你的熱路徑畫出來，再談語言。看 p50、p95、p99，別只看平均值。CPU 密集、成本敏感、延遲要求高的路徑，Rust 值得認真評估。只是包著 API、串外部系統、做控制平面的服務，Go 很常已經夠用了。

Rust 的 ownership 是在幫你省錢，不是在跟你炫技

我最在意的其實是記憶體那段。很多人講 Rust 只會講「borrow checker 很煩」，但那只是開頭。真正有感的是，ownership 和 borrowing 會把一大票記憶體問題擋在編譯期。Go 的 GC 已經比以前好很多了，這點我不否認，但它還是用 runtime overhead 跟記憶體頭寸去換開發便利。

Tech Insider 提到 Rust web server 常見大概落在 50-80 MB RAM，而相近的 Go 服務可能到 100-320 MB。這個區間很大，我不會把它當聖旨，但方向很清楚。文章也提到 Go 1.24 的 GC pause 通常在 500 微秒以下，對很多服務來說夠用。夠用就是夠用，不代表沒有成本。

我碰過一個 Go 服務，前期看起來超乖，功能也好改。結果流量上來後，記憶體一路膨脹，GC 在 profiling 裡越來越顯眼。服務沒壞，但它開始變貴。那種貴不是雲帳單突然爆炸，而是你每次加功能都要多想一層：這段 allocation 會不會又把 tail latency 拉歪。

實操寫法：如果你的服務有明確 memory ceiling，或你很在意 deterministic cleanup，Rust 的模型會很有價值。如果你的團隊現在最缺的是交付速度、需求還在亂飛、產品也還沒長成固定形狀，Go 的 GC 會少掉很多你現在不想處理的摩擦。

• 記憶體預算緊，就先看 Rust。
• 團隊還在磨基本交付節奏，就先看 Go。
• compile-time safety 很香，但它不是免費午餐。

Go 的 goroutine 還是最少折騰的併發解法

Rust 這幾年在 async 已經進步很多，尤其是 Rust 1.83 把 async closures 穩定下來之後，寫法比以前順一點。但老實講，Go 的併發模型對大多數團隊還是比較乾脆。goroutine 便宜、好起、好理解，channel 也夠直接，很多 cloud-native 工具跟服務碼就是靠這套活下來的。

Rust async 很強，這句我同意。可它還是要你處理 lifetime、executor、pinning 這些認知負擔。不是不能學，是你要付出更多腦容量。Rust 官方文件寫得很完整，但完整不等於輕鬆。我看過不少團隊導入 Rust 後，花很多時間在教大家怎麼不要跟 compiler 打架。

我自己最有感的是，Go 很適合把很多 socket、很多 worker、很多外部呼叫先跑起來。你要 fan out、要做 service mesh 周邊、要寫控制器，Go 的路徑通常比較短。Rust 也能做，但你常常會先多出一段設計成本。

實操寫法：如果你的團隊要處理大量併發請求、事件分派、或 infra tooling，Go 通常比較快落地。如果你在意 allocation、tail latency、或你寫的是 async-heavy 的底層服務，Rust 的 async 改善後，比以前更值得考慮，但不要假裝它已經和 Go 一樣省腦力。

• Go 適合先把併發做出來。
• Rust 適合把併發做得更精準。
• Rust 1.83 有幫助，但沒有把學習曲線抹掉。

開發體驗這件事，Go 還是很會贏會議

文章講得很直白：新手學 Rust 可能要花幾週到幾個月摸懂 borrow checker，Go 開發者通常幾天就能進狀況。這個我完全買單。Go 是我在團隊要先把服務送出去時會選的語言；Rust 是我在知道 runtime 成本遲早會回來咬人時才會選的語言。

Tech Insider 也提到 Rust 1.83 的 async closures、Go 1.23 的 generics、native OpenTelemetry 整合，還有 log/slog 的結構化 logging 改善。這種演進很重要，因為它會改變「難」的定義。Rust 在補 async 的坑，Go 在把 observability 跟型別約束弄得更順。

我看過很多 review，團隊嘴上說要 Rust 是因為效能，結果真正想要的是更強的 correctness 保證跟更乾淨的 failure mode。這理由很合理，只是它不是「我們要更快」那種理由。你如果把兩件事混在一起，最後通常會得到一個又慢又難養的系統。

實操寫法：直接問團隊兩句。第一句，為了更強的 compile-time 保證，我們能不能接受比較慢的上手？第二句，我們是真的有 performance 問題，還是只是習慣先假設有？如果前者答案是否，Go 通常比較穩。這不是保守，這是少走冤枉路。

生態系的差距，比語言口水戰更有用

文章說 Go 在 CNCF 生態裡的滲透很高，這種資訊比什麼「哪個語言比較潮」有用太多。如果你在做 Kubernetes 周邊、infra controller、cloud-native plumbing，Go 的生態重力很難忽略。相反地，如果你做的是安全敏感軟體、底層系統、或對效能很挑的服務，Rust 的勢頭很明顯，而且還在往上。

它也提到 Rust 在 2026 年 1 月到 TIOBE 第 13 名，還有 Rust Blog survey 顯示 48.8% 的組織在 2025 年有非小型 production use，2023 年是 38.7%。我不會把這些排名當神諭，但方向很重要。Rust 已經不是只有愛好者在玩，它開始進到那些對 memory safety 和 correctness 有硬需求的地方。CNCF 的專案分布本來就很能反映這件事。

實操寫法：不要問「哪個語言比較好」，去問「哪個生態已經幫我解掉大部分周邊問題」。如果你要的是雲原生整合，Go 常常省時間。如果你要的是記憶體安全、可預期資源釋放、較小 runtime footprint，Rust 可能在整個系統生命週期裡更划算。

我也真的看過兩者混用的組合：Go 放在外圍，Rust 放在 hot path。這種切法通常比硬要全棧單一語言更正常，至少不會把所有風險一次押在同一邊。

薪資差距是市場訊號，不是選型捷徑

文章說 Rust 職位平均年薪是 178,000 美元，Go 是 165,000 美元，還提到 Rust 在安全敏感領域的需求成長更快。這些數字是真的有參考價值，但我不希望你把它讀成招募簡報。薪資高通常代表工作更難、候選人更少，或兩者都有。Rust 很常就是兩者都有。

這不代表你該因為薪資高就去選 Rust。我看過太多爛架構是這樣來的：先被市場熱度吸走，再回頭硬找技術理由。正確問法是，你的產品到底有沒有吃到 Rust 那些約束帶來的好處。如果有，人才成本比較高也許值得。如果沒有，你只是花更多錢讓 onboarding 更難。

實操寫法：把薪資資料當市場訊號，不要當技術答案。如果你所在區域 Rust 人才稀缺，就要把招募跟 ramp-up 成本算進去。如果 Go 人才比較多，而你的工作型態又偏 service-heavy，不偏 compute-heavy，那你很可能用 Go 拿到更高的總產出。

Benchmark 只能當篩子，不能當判決書

我最怕看到有人把 benchmark 文當法院判決。那種用法最偷懶。Tech Insider 這篇其實給了夠多細節，但前提是你要把數字對回自己的工作負載，不然看再多也只是看熱鬧。

我的粗暴規則很簡單：你要的是更緊的記憶體控制、更低的 tail latency、更強的 compile-time 保證，而且願意付出複雜度，就看 Rust。你要的是快速上手、簡單併發、運維上比較省事，而且 runtime「夠用就好」，就看 Go。就這樣，沒有什麼神秘配方。

實操寫法：先把 workload 寫清楚，再決定語言。列出 CPU intensity、memory ceiling、併發模式、團隊經驗、部署限制。然後拿這些條件去對語言，而不是去對 benchmark 標題。這樣你才不會被數字牽著鼻子走。

我自己現在看語言選型，越來越少看誰贏了誰，越來越多看誰比較像這個系統該有的樣子。這種答案通常比較無聊，但也比較不會害你半夜救火。

可抄的模板

## Rust vs Go 2026 選型模板

### 1) 先寫清楚服務在做什麼
- CPU-heavy： [是 / 否]
- I/O-heavy： [是 / 否]
- 對 tail latency 敏感： [是 / 否]
- 記憶體預算很緊： [是 / 否]
- 團隊已經懂 Rust： [是 / 否]
- 團隊已經懂 Go： [是 / 否]

### 2) 這個專案最重要的是什麼
- 最快交付速度： Go
- 最低 runtime memory： Rust
- 最低 p95 / p99 latency： Rust
- 最好 onboarding： Go
- 最適合 cloud-native 生態： Go
- 最強 compile-time safety： Rust

### 3) 直接下決策
如果服務主要是 API、控制平面、cloud-native plumbing，先選 Go。
如果服務是 compute-heavy、memory-sensitive、或 latency-critical，先選 Rust。
如果團隊兩邊都不熟，沒有硬性 runtime 約束時，先選 Go。

### 4) 先做這些 benchmark 再決定
- p50 / p95 / p99 latency
- RSS / peak memory
- CPU utilization under load
- build time / deploy time
- 小功能的開發 ramp-up 時間

### 5) 小規模導入方式
- 先挑一個 service 或一段 hot path
- 保持 interface 夠窄
- 先定成功標準，再開始重寫
- 用真實流量跑一週後再看數字
- 如果運維成本上升，就直接停

### 6) 最後一句話
Rust 適合 runtime predictability 是產品需求的情況。
Go 適合 team throughput 和 operational simplicity 是產品需求的情況。

這段我真的會直接丟給團隊。它會逼大家把討論從 vibe 拉回 constraint。語言選型本來就該這樣，不要拿信仰在那邊互相按摩。

來源致謝：這篇拆解主要來自 Tech Insider 的 Rust vs Go 2026 比較，另外參考了 Rust 官方網站、Go log/slog 與 CNCF。上面的分析框架、白話翻譯跟可抄模板是我自己的整理。