Bun 把 Rust 重寫計畫推到檯面上後，網路很自然地開始分隊。

一邊急著把它寫成「Zig 終究不行」。另一邊立刻防守：「Rust 粉又來了」。討論很快被拉進語言陣營。

這件事的重點不只是哪個語言贏了什麼，而是大型開發者工具在公開底層遷移時，敘事框架會先被誰寫下來。團隊沒有先說清楚，網路就會把複雜的工程取捨壓成 Rust 贏、Zig 輸。

Clawd 想補充：

技術圈最愛語言戰，因為它很好吵：Rust 安全、Zig 靈活、C++ 老兵不死、Go 工程師準時下班。問題是這種吵法通常資訊量很低，像拿扳手互敲，聲音很大，螺絲沒轉半圈。

(・∀・)

Zig 不是失敗者，它是把 Bun 扛到這裡的腳手架

Bun 專案 PR #30683 規模不小：刪掉剩下的 1290 個 Zig 檔案，把內部 Zig 命名改成 Rust 對應版本，並把程式碼生成路徑從 Zig 檔案轉到 Rust 檔案。這不是換幾個標誌，而是產品底層語言遷移的最後清場。

Bun 能靠 Zig 走到今天，代表 Zig 至少完成了早期產品階段的任務。

Bun 是 JavaScript 執行環境、套件管理器、打包器、測試工具，加上一整串開發者工具的集合體。能把這種產品推到市場上、跑出社群影響力，Zig 在這段路上的角色很難只用「最後還不是轉 Rust」概括。

這次遷移可以被整理成兩層：Zig 給了早期速度、系統控制與產品探索空間；Rust 則是下一階段針對穩定性、記憶體安全與團隊維護性的選擇。這樣的說法能把早期選型與後期風險模型分開。

沒有這層，討論就容易掉回陣營戰，把一個工程決策壓扁成比分板。

更大的變化：語言鎖定正在鬆動

過去大型專案一旦選定程式語言，後面多年通常都會被那個選擇綁住。因為重寫成本太高、團隊技能太固定、工具鏈太重，語言不是一個模組，而是一整座地基。

Bun 這次提供了一個可觀察案例。

Bun 轉 Rust 很容易被看成 Rust 的勝利，但也可以提出另一個問題：如果大型產品真的能從一個系統語言遷移到另一個系統語言，語言鎖定是不是沒有過去那麼絕對？

這不是說重寫真的變便宜了。大型重寫還是很貴，尤其牽涉執行環境、外部函式介面、程式碼生成、測試矩陣時，更不是下午泡杯咖啡就能搬完。

因此這個案例比較適合被讀成一個問題，而不是結論：選語言不只是在問「哪個語言最好」，也在問「哪個語言在這個產品階段、這個風險模型、這個團隊配置下，提供最好的交換條件」。

Clawd 偷偷說：

這有點像創業公司一開始用 Notion 管全公司，後來換成 Linear、GitHub Issues、內部工具。Notion 沒有因此變垃圾，它只是完成了某個階段的任務。工具被替換，不等於工具被否定。

記憶體安全不是魔法，是一組邊界保證

Rust 在這場討論裡最強的牌，當然是記憶體安全。Bun 自己也面對過崩潰、原生程式邊界、執行環境複雜度這些問題。Rust 的型別系統與借用檢查器，確實能把很多原本會在執行期爆炸的錯誤，提前推到編譯期。

但「因為 Zig 不夠安全，所以換 Rust」這種版本太省略。對剛進場的工程師來說，可以先把問題拆成幾個比較像日常維修的層次：

  • 記憶體配置器像倉庫管理員，負責發空間、收空間；帳本亂掉，就可能拿到已經被回收的格子。
  • 外部函式介面是不同語言之間的海關。貨物格式、所有權、壽命講不清楚，過關後就很容易爆。
  • JIT 邊界像一邊開車一邊鋪路。程式跑到一半才生成機器碼，邊界條件錯了，事故不一定發生在原本寫錯的那一行。
  • 並行狀態是很多人同時改同一張白板。沒有規則，就會有人擦掉別人剛寫上的字。
  • API 契約則是團隊之間的合約。呼叫方以為可以這樣用，被呼叫方其實沒保證，那就是日後事故的伏筆。

Rust 可以把其中一部分錯誤變成編譯器會先抓到的紅燈，但不是每一種事故都會自動消失。真正該問的是：Bun 最常在哪一層出事？哪些錯誤是 Rust 能擋的？哪些還是要靠測試、審查、架構邊界和團隊流程？

開發者工具賣的不只是功能，還有信任

Bun 如果能把崩潰類型、遷移前後的事故率、測試策略、Rust 擋下的錯誤類別整理出來，其他系統語言專案就會更容易從這次遷移裡學到東西。

這裡的關鍵不是再補一句「不要吵語言戰」。前面已經講過了，讀者也懂。更值得停下來看的是：開發者工具公司每一次公開底層大改，其實都在回答採用者心中的同一個問題：這個團隊到底怎麼做風險判斷？

一般應用程式換內部技術，使用者多半只在乎有沒有變快、變穩、變便宜。開發者工具不一樣。Bun 這種東西會進到本機、CI、部署流程、團隊習慣，甚至影響未來好幾年的技術債。所以遷移理由不能只寫給語言社群看，也是在寫給所有把工作流押上去的人看。

Clawd 忍不住說：

開發者受眾不是不能接受大改。開發者每天都在重構爛系統，沒有人天真到以為第一版架構會永遠神聖。真正讓人緊張的是團隊把大改講得像打臉前任技術選型。那會讓採用者心裡冒出一句話：下一個被打臉的，會不會就是現在這個選擇？

結語

技術遷移需要把「上一階段為什麼可行」和「下一階段為什麼要換」同時講清楚。

Zig 不需要被寫成輸家，Rust 也不需要靠踩 Zig 才顯得合理。Bun 這次能教人的，是大型產品如何在速度、穩定性、記憶體安全、工程紀律之間重新配重。

語言會換，遷移理由會留下。

如果後續有更多公開資料，最有價值的不是哪邊又贏了一局，而是崩潰分類、事故率變化、測試策略，以及 Rust 實際擋下的錯誤類別。把重寫講成戰報，只會多一場吵架；把重寫講成事故復盤，整個社群才會變聰明。