Rust 的務實限制:何時該使用,何時該放棄
在當前的系統程式設計領域中,Rust 經常被視為萬靈丹——一種既能提供 C++ 的效能,又能具備受控語言安全性的語言。產業趨勢顯而易見:Amazon、Cloudflare 和 Discord 等巨頭正將關鍵基礎設施遷移至 Rust。對於許多工程經理和架構師而言,自然而然的反應就是跟進這一趨勢。
然而,採用 Rust 的決定不應基於企業趨勢,而應基於對專案需求和團隊能力的冷靜分析。雖然 Rust 由編譯器強制執行的正確性是一項強大的資產,但這也帶來了生態系統碎片化、學習曲線以及維護開銷等顯著成本。
Rust 生態系統的摩擦力
Rust 開發中最具爭議的領域之一是其處理非同步程式設計的方式。雖然 async 是高效能網路服務的核心需求,但它引入了多層複雜性:
非同步複雜性陷阱
Async Rust 往往會使該語言最著名的特性:所有權(ownership)變得複雜。泛型(generics)、生命週期(lifetimes)與 async blocks 的交集可能導致脆弱的程式碼,使得微小的需求變動就必須對所有權假設進行大規模的重寫。此外,阻塞事件迴圈(event loop)的風險仍是一個持續存在的問題;在 async 上下文中意外呼叫同步函數,可能會導致難以除錯的效能不一致,甚至導致阻斷服務(DoS)漏洞。
生態系統碎片化
與具有「內建完善功能」(batteries-included)哲學的語言不同,Rust 的生態系統高度碎片化。由於像 tokio 這樣的關鍵運行時(runtimes)並非官方標準函式庫的一部分,社群因此分裂成同步與非同步版本的函式庫。這造成了顯著的「雜務」,因為開發者經常發現自己必須撰寫封裝器(wrappers)來使同步程式碼與非同步運行時相容。
維護負擔:專案衰退與穩定性
對 Rust 的常見批評是其演進速度。隨著幾年內發布了數十個版本,該語言的變動非常迅速。對於一個可能在一段時間內不被更動,然後再進行更新的專業專案而言,這種快速迭代可能是一種負擔。
批評者認為,程式語言應該作為穩定的平台,而非快速變動的產品。當一種語言快速引入新功能時,它會鼓勵函式庫作者追求「每月新功能」,導致依賴樹(dependency tree)的劇烈變動。這可能導致「供應鏈噩夢」,即單個小型專案可能因為各種上游依賴選擇了不同的實作方式,而依賴於同一個加密函式庫的多個不同版本。
「貧血」的標準函式庫
Rust 重度押注於進階的型別理論與語言能力,但有人認為這這是在犧牲一個強大的標準函式庫。與提供全面且經過審核的加密原語(cryptographic primitives)與網路工具的 Go 語言相比,Rust 依賴於一系列社群 crates。
雖然像 hyper 和 tokio 這樣的函式庫品質很高,但由於缺乏官方、統一的基礎工具標準(例如日期時間或加密),導致了碎片化的景象。這增加了安全關鍵型應用程式的審核範圍,因為開發者必須審核多個第三方 crates,而不是依賴於單個由語言維護的實作方式。
Rust 真正卓越的領域
儘管有這些缺點,Rust 並非適用於每個專案的通用工具;相反地說,它是一種針對特定高風險環境的精密儀器。
1. 跨平台應用程式的共同核心
Rust 在構建針對行動裝置(iOS/Android)、桌面端與網頁(透過 WebAssembly)的共享函式庫方面具有獨特的地位。它在所有這些目標平台上提供記憶體安全與高效能的依賴管理能力,使其成為 WhatsApp 和 Signal 等應用程式所採用的「共同核心」架構的理想選擇。
2. 系統程式設計與嵌入式開發
對於系統守護程序(daemons)與 IoT 裝置,Rust 的低資源消耗與記憶體安全是具備變革性的。在嵌入式領域,儘管 C 語言因其容易受到記憶體錯誤影響而長期統治,但 Rust 提供了一個更安全的替代方案,特別是晶片製造商開始提供官方的硬體抽象層(HALs)。
3. 極大規模運作
當運作規模達到 AWS 或 Cloudflare 的等級時——即每一微秒的 CPU 時間與每一位元組的 RAM 都會轉化為數百萬美元的基礎設施成本時——權衡的邏輯就會改變。在這些情況下,能夠在維持正確性的同時從硬體中榨取最大效能的權衡,其價值超過了生態系統的摩擦力。
反對觀點與社群觀點
並非所有開發者都同意 Rust 的「限制」。有些人認為所察覺到的「衰退」是被誇大的,並指出 Rust 的「版本」(editions)設計旨在特別地維持後向相容性,允許開發者在準備好遷移時才進行遷移。
其他人則指出,「貧血」的標準函式庫是一個刻意的設計選擇,旨在保持語言的精簡與讓生態系統能比中央委員會所允許的更快速地演進。從這個角度來看,async 的複雜性僅僅是為了在一個沒有垃圾回收機器的語言中實現真正的零成本抽象(zero-cost abstractions)所付價的代價。
最終,務實主義者之間的共識是:Rust 是一個工具,而非宗教。對於高效能系統與跨平台核心,它是卓越的選擇;但對於標準的中型後端服務,Go 或 Python 的生產力可能會是更理性的選擇。