Async Rust 從未脫離最小可行性產品（MVP）階段

背景

本文探討了 Rust 非同步（Async）機制在現階段的侷限性，特別是在嵌入式系統等對二進位檔案大小極度敏感的場景中。作者指出，目前的編譯器生成的狀態機包含過多冗餘的狀態與恐慌（Panic）檢查路徑，導致非同步代碼無法達到真正的「零成本抽象」，並提議透過優化 MIR 階段的狀態機生成來減少二進位體積。

社群觀點

針對文章提出的優化建議，Hacker News 社群展開了多層次的討論。部分開發者認為文章標題過於聳動，指出作者過度關注微小函數的開銷，而忽略了在大多數實際應用中，非同步區塊的邏輯通常足夠龐大，足以稀釋掉這些狀態機的基礎成本。然而，這種觀點隨即遭到反駁，支持者認為非同步代碼在 Rust 中往往是深度嵌套的，每一層間接調用所累積的運行時開銷與二進位膨脹，在大型專案中會產生顯著的複合效應，這對於追求極致性能與小體積的嵌入式開發者而言，絕非微不足道的細節。

討論中也觸及了非同步編程模型本質的爭議。有留言者批評當前的非同步機制是「未成熟的產物」，認為傳統的執行緒模型在邏輯上更為直觀且易於維護。他們指出，非同步語法最初是為了修復回呼函數（Callback）帶來的混亂，但卻引入了函數著色與複雜的調度問題，這在某種程度上是倒退回了 1970 年代的調度模型。對此，另一派觀點則強調執行緒與非同步各有其適用場景，非同步機制在處理高併發與跨平台移植時具有不可替代的優勢，且內核執行緒的上下文切換成本在高性能需求下往往過於昂貴。

此外，社群對於 Rust 編譯器在優化上的「懶惰」也有所共鳴。開發者提到，雖然 LLVM 在某些情況下能處理簡單的優化，但當非同步調用鏈變得複雜時，編譯器往往無法識別出那些永遠不會觸發的錯誤路徑。這種關於底層實作細節的討論，被視為 Rust 走向成熟的必經之路，類似於 C++ 社群長期以來對底層開銷的斤斤計較。儘管存在爭議，多數留言者仍肯定這類深度技術分析的價值，認為這有助於推動 Rust 脫離目前的「最小可行性產品（MVP）」狀態，朝向更精簡、更高效的方向演進。

延伸閱讀

在討論過程中，有開發者提到 Rust 官方倉庫中編號 #135527 的拉取請求（Pull Request），該提案正試圖解決 Future 體積過大以及不必要的數據拷貝問題，這與本文所探討的優化方向息息相關。