JavaScript 執行環境 Bun 最近再次成為開發者社群焦點。這次不是因為新的效能測試，也不是 Node.js 相容性更新，而是因為 Bun 創辦人 Jarred Sumner 在 X 上表示，一個實驗性的 Rust 改寫版本，已經能在 Linux x64 glibc 環境下通過 Bun 既有測試套件的 99.8%。這個數字迅速被 Hacker News 社群推上熱門討論，也引發 Zig、Rust、AI coding agent 與開源維護模式之間的一連串辯論。
這件事最容易被誤讀成一句話，Bun 要放棄 Zig、全面改用 Rust。但比較準確的說法應該是，Bun 團隊正在公開探索一條由 AI 協助、從 Zig 遷移到 Rust 的可行路徑，目前仍是實驗，不代表主線版本已經決定轉向。
從 16,000 個編譯錯誤到 99.8% 測試通過
根據 Jarred Sumner 在 X 上的說法，這個 Rust 改寫版本在 Linux x64 glibc 上，已經通過 Bun 既有測試套件的 99.8%。他進一步表示，這不是簡單丟一句Claude，幫我把 Bun 改寫成 Rust就完成的工作，而是一個約 96 萬行程式碼規模的改寫實驗，從端到端來看，他大約是在六天前開始投入這項工作。
更值得注意的是，Jarred 在 Hacker News 回應中補充，幾天前這個分支甚至還有超過 16,000 個 cargo check 編譯錯誤，無法印出版本號，也無法執行 JavaScript。也就是說，這次引發討論的重點，不只是Rust 版本測試通過率很高，而是 AI 輔助重構在極短時間內把一個大型系統軟體專案推進到可測試階段。
不過 CyberQ 觀察認為，這裡仍有幾個限制必須講清楚。第一，99.8% 是在特定平台 Linux x64 glibc 上的測試套件通過率，不代表所有平台、所有實際工作負載、所有 Node.js 相容情境都已完成驗證。第二，測試通過不等於長期可維護。第三，這仍然不是官方正式宣布 Bun 將從 Zig 轉向 Rust 的產品決策。
Jarred 先前在另一個 HN 討論中已明確表示，這個分支是他的實驗，Bun 團隊尚未承諾要重寫，而且這些程式碼有很高機率最後會全部丟掉。他的目的，是想比較一個可運作 Rust 版本與現有 Zig 版本在效能、記憶體使用、可維護性與開發體驗上的差異。
為什麼 Bun 原本選 Zig？
Bun 之所以受到開發者關注，主要是因為它不是單一工具，而是一套整合式 JavaScript 與 TypeScript 工具鏈。官方文件描述，Bun 是一個 all-in-one toolkit，包含 runtime、package manager、test runner、bundler 等功能，並以單一 bun 執行檔形式提供。Bun 核心目前是以 Zig 撰寫，底層使用 Apple Safari 所採用的 JavaScriptCore 引擎，而不是 Node.js 與 Deno 使用的 V8。
這個設計讓 Bun 在冷啟動、打包、安裝套件與伺服器端執行等情境中，長期主打效能優勢。Bun 官方 GitHub README 也仍然明確寫著，Bun runtime 以 Zig 撰寫，並由 JavaScriptCore 驅動。GitHub 頁面顯示其語言組成仍以 Zig 為最大宗，其次是 C++、TypeScript、C 與 JavaScript。
因此，這次 Rust 實驗對 Zig 社群的衝擊才會這麼大。Bun 一直被視為 Zig 在大型實戰專案中的代表案例之一。如果 Bun 最終真的轉向 Rust，象徵意義會遠超過一個 JavaScript runtime 的內部實作選擇。
為什麼 Jarred 想試 Rust？
Jarred 在 X 串文中的理由相當直接。他表示，Rust 版本基本上仍是同一套程式邏輯，但可以讓編譯器協助檢查型別生命週期，也能在需要時使用 destructor，同時，Rust 會把比較危險或不漂亮的地方用 unsafe 暴露出來，反而會促使開發者重構。
他的核心動機也很清楚，他已經厭倦花大量時間處理記憶體洩漏、crash 與穩定性問題，希望語言本身提供更強的工具，協助防止這類問題。這點正好呼應 Rust 官方長期主打的價值，Rust 透過型別系統與所有權模型，在編譯時期協助處理記憶體安全與執行緒安全問題。
不過，這不代表 Rust 可以自動消滅所有穩定性問題。Rust 仍然可以寫出記憶體洩漏，也可能因 unsafe、FFI、生命週期設計不良、資源管理錯誤而出問題。真正的差別在於，Rust 會把許多風險提早推到編譯期與型別設計階段，讓大型專案更容易建立可被工具檢查的邊界。
開發者意見分歧
CyberQ 觀察，Hacker News 討論串的標題是Bun 的實驗性 Rust 改寫在 Linux x64 glibc 上達到 99.8% 測試相容，有不少人轉發和留言，顯示開發者社群對此事的高度關注，而討論大致分成下面這幾種方向。
第一派認為，這是非常合理的工程實驗。大型系統軟體如果長期受到記憶體安全、crash、資源回收與維護成本困擾，用 Rust 建立一個可比較版本，本來就是值得做的事。
第二派擔心，AI 轉寫出來的程式即使能通過測試，也不代表可維護。這類觀點認為，軟體不是只有能跑就好，更重要的是未來的工程師能不能理解、審查、修改與擴充。尤其對 runtime 這類底層工具而言，測試套件覆蓋不到的邊界條件，往往才是最危險的地方。
第三派則把焦點放在 Zig 與 Rust 的語言選擇。有人認為 Zig 的手動記憶體管理與低階控制能力仍然適合高效能 runtime，也有人認為 Bun 這種已經被大量使用的基礎設施，應該更重視 Rust 提供的型別安全與資源管理約束。
第四派則看見更大的趨勢，AI coding agent 正在改變大型重構的成本結構。過去要把一個近百萬行等級的系統從一種語言遷移到另一種語言，通常是數月甚至數年的工程，現在至少在產生可運作原型這個階段，AI 已經大幅降低試驗門檻。
Anthropic 收購 Bun 之後讓這件事更敏感
這次事件還有一個重要背景，Bun 已在 2025 年底加入 Anthropic。Bun 官方部落格表示，Bun 已被 Anthropic 收購，Anthropic 將 Bun 視為 Claude Code、Claude Agent SDK 與未來 AI coding tools 的基礎設施，但 Bun 仍會維持開源與 MIT 授權，並繼續在 GitHub 上公開開發。
Anthropic 官方新聞稿也指出，收購 Bun 是為了進一步加速 Claude Code，並稱 Bun 是 runtime、package manager、bundler 與 test runner 整合的 all-in-one toolkit。Anthropic 同時表示，Bun 將繼續維持 open source 與 MIT 授權。
這讓 Rust 改寫實驗帶有更強的產業訊號。它不只是個人開發者的語言偏好，而可能反映 AI coding 時代對開發基礎設施的新要求，速度仍然重要，但穩定性、可預測性、可自動化測試、可由 AI agent 理解與修改的程式結構，會變得更重要。
Jarred 在 Bun 加入 Anthropic 的文章中提到，近幾個月 Bun repo 中合併最多 PR 的 GitHub 使用者，已經是一個 Claude Code bot， AI agent 已經開始進入大型開源專案的日常維護流程。
這不是Zig 輸了，而是大型軟體維護模式變了
把這件事解讀成 Rust 打敗 Zig 其實太簡化。Zig 仍然有它的優勢，尤其是在明確控制記憶體配置、編譯流程、跨平台建置與低階系統程式設計方面。Bun 當初能以驚人的速度切入 JavaScript 工具鏈市場，Zig 顯然是重要原因之一。
但當一個工具從新興高效能專案變成 AI coding infrastructure 的一部分時，評估標準就會改變。早期專案可以靠少數核心高手理解全部低階細節，成熟基礎設施則必須考慮更多維護者、更多平台、更多使用案例，以及更長期的穩定性壓力。
Rust 的吸引力在這裡不只是效能，而是它把許多維護規則變成編譯器可檢查的約束。對人類工程師如此，對 AI coding agent 更是如此。當 AI 生成大量程式碼時，語言與工具鏈能否及早攔截危險模式，可能會成為架構選型的重要條件。
CyberQ 觀點
截至目前，Bun 並沒有正式宣布主線版本將全面從 Zig 遷移到 Rust。Jarred Sumner 的說法是，這是一個實驗性 Rust rewrite，用來驗證效能、記憶體使用、可維護性與工程可行性。99.8% 測試通過率很驚人，但它仍只是特定平台與既有測試套件下的里程碑，不應被解讀為生產環境已準備完成。
真正值得關注的是另一件事，AI coding agent 已經開始讓大型語言遷移與系統級重構，從幾乎不可想像變成可以快速做出可比較原型。這不代表人類工程師的重要性下降，反而代表審查、架構判斷、測試設計、安全邊界與維護策略會變得更重要。
Bun 這次事件也許最後不會導向正式 Rust 版本，但它已經讓我們可以去思考未來軟體工程的另一種新的現實。我們有些客戶也正在進行這方面的工作，讓 AI 在幾天到數周內完成過去耗時幾個月等級專案的重構初稿。這也讓我們重新想像，企業與開源專案接下來要問的，不再只是能不能改寫，而是改寫後能不能被信任、被維護、被驗證囉。
