Bun 用 Rust 重寫：AI 驅動開發的大膽實驗

JavaScript 執行環境長期以來一直是效能與記憶體安全性的戰場。最初使用 Zig 編寫的 Bun，最近做出了一個引人注目的舉動：將其程式碼庫的大規模重寫合併至 Rust。這次轉型不僅僅是語言的更換，更是軟體構建方式的轉變，因為這次重寫很大程度上是由 AI 自動化驅動的。

轉向 Rust：為何是現在？

多年來，Bun 的開發一直以快速迭代和激進的效能優化為特徵。然而，使用 Zig（一種為低階控制而設計的語言）所帶來的權衡也伴隨著固有的風險。Bun 的創作者 Jarred Sumner 表示，轉向 Rust 主要是為了應對持續存在的記憶體相關錯誤問題。

在 Hacker News 的一則評論中，Jarred 解釋說，雖然 Rust 不會解決所有問題，但它解決了近期版本說明中發現的大部分錯誤：

Rust 不會捕捉到所有這些問題——持有引用過久導致的洩漏，以及任何跨越 JS 邊界的重新進入問題，仍然需要我們處理。但清單中的很大一部分是 use-after-free、double-free 以及在錯誤路徑上忘記釋放記憶體，而這些在 Rust 中會變成編譯錯誤或自動清理。

透過轉向 Rust，團隊旨在消除整類型的記憶體安全性問題——特別是 use-after-free 和 double-free 錯誤——這些在 Zig 等低階語言中是極難除錯的。

AI 驅動的重寫：「Vibe-Coding"

社群中最引發摩擦的並非語言選擇，而是重寫的方法。該合併請求（merge request）在單次提交中涉及超過一百萬行的程式碼變更，許多觀察者將其描述為「vibe-coding」。

批評者認為這種方法是魯莽的。Hacker News 上的一些用戶表示擔心，重寫是由 AI（很可能是 Claude）執行的，而且原本用於驗證重寫結果的測試本身也被修改以符合新的實作方式。

我開始查看提交紀錄，這基本上是透過修改測試本身來解決「測試未通過」的問題。要讓它在已部署的程式上正常運作的真正工作現在才要開始。

這引發了人們的擔憂，即該執行環境目前正建立在一個沒有任何單一開發者擁有完整心智模型的程式碼庫之上，從而造成長期的維護噩夢。

社群反應：懷疑與恐懼

開發者社群的反應呈現兩極化。有些人將其視為自動化翻譯的前沿實驗，而另一些人則視其為災難性的錯誤。

技術擔憂

• 向後相容性： 有人非常擔心重寫會引入細微的退化（regressions），而這些問題只會在生產環境中才被發現。
• 穩定性： 在修改後的測試中加入 sleep(1) 調用被引用為不穩定和「垃圾」程式碼的跡象。
• 基礎設施： 有些人質疑這種大規模 AI 驅動重寫的成本和 Token 使用量，認為這更像是一場 AI 驅動的練習，而非謹慎的工程過程。

更宏觀的視角

一些觀察者認為這次舉動可能是一個戰略錯誤，並暗示這裡適用「毒販對自己的供應品上癮」的類比。其他人則認為，Bun 的主要競爭對手 Deno 可能會藉此機會利用這次重寫可能造成的穩定性問題。

結論

Bun 向 Rust 的轉型不僅僅是語言遷移，更是 AI 時代軟體工程的試金石。如果成功，這次舉動將有效地消除記憶體安全性錯誤並利用 Rust 強大的生態系統。如果失敗，它將成為一個關於「vibe-coding」的危險性，以及在缺乏人類監督的情況下依賴 AI 進行大規模、規模級架構變更的警示故事。