Bun 改寫 Rust，完成了嗎？
Bun 想把原本以 Zig 為主的核心機械式移植到 Rust，利用 borrow checker、Drop 與既有測試降低記憶體錯誤，同時維持 JavaScript runtime、套件管理、測試與 bundler 的相容性。團隊以 Claude Code 同時跑約 50 組動態工作流，讓實作者、兩名對抗式 reviewer 與修正代理分工；11 天產生 6,778 次 commit、超過百萬行 diff，並讓約六萬項跨平台測試通過。不過這代表程式已合併到 main，不等於正式版已經可交付。
現實應用
這套做法適合測試完整、行為邊界清楚的大型程式移植，例如 runtime、compiler、資料庫引擎或跨語言基礎建設。一般產品團隊也能借用「小規模試跑、機械式轉換、獨立代理審查、CI 回饋修正」流程，但前提是有足夠測試、運算資源，以及能看懂底層程式的工程師。缺少這些條件，把大量程式碼生成出來只會提早撞上 review 與驗證瓶頸。
期望評估
我認為低標成果已經成立：AI 能把原本可能耗時數月的移植工作壓縮成可編譯、可測試的候選版本，並協助找出記憶體洩漏與跨語言差異。高標則是 Bun v1.4 正式發布後，真的維持相容性、降低維護成本，並達成官方宣稱約 20% 較小 binary、部分工作負載快 2%～5%。但原文在 7 月 27 日觀察到仍無正式 release tag，且 robobun 尚有 2,475 個 open PR；這些不能直接等同未完成工作量，卻足以說明後續整併仍很重。
商業策略分析
我認為真正受影響的是開發工具商、雲端 CI 業者與大型開源專案：競爭焦點會從「模型能不能寫 code」轉成「誰能負擔驗證、算力與資深工程監督」。官方揭露合併前 API 定價約 16.5 萬美元，但未納入後續 CI 與維護成本；原文推估總投入可能逼近 80 萬美元，這是作者假設，不是官方數字。我猜值得跟進的是工作流設計，不是照抄燒錢規模；正式 release、回歸率與半年後維護效率，才是這次實驗有沒有商業價值的判準。
實作細節
目前 Rust 版以 canary 提供，可執行 bun upgrade --canary。官方表示約 4% Rust 程式位於 unsafe block，因為仍需銜接 JavaScriptCore 與 C/C++ library；移植曾帶來 19 個已知 regression，官方稱均已修正。正式環境仍建議等待 Bun v1.4 stable，或先用現有測試與流量影子驗證。