使用 Zig 語言編寫 C 編譯器

背景

本文源於一位正處於待業期的開發者，為了學習 Zig 語言並打發時間，參考 Nora Sandler 的著作《Writing a C Compiler》所撰寫的一系列實作紀錄。作者將其專案命名為 paella，詳盡記錄了從零開始用 Zig 打造 C 編譯器的過程，並在 Hacker News 上引發了關於 Zig 語言特性、編譯器架構以及開發者體驗的深入討論。

社群觀點

針對這項專案，社群首先討論到 Zig 與 C 語言之間的深厚淵源。有評論指出，用 Zig 編寫 C 編譯器非常符合該語言早期提出的「以 Zig 維護 C」的核心價值主張。雖然目前 Zig 的工具鏈（如 zig cc）主要仍依賴於內置的 Clang 與 LLVM 框架，但長遠來看，社群普遍期待 Zig 能逐漸降低對 LLVM 的依賴。事實上，Zig 社群已經出現了更為成熟的 C 編譯器實作，例如 Aro 專案，Zig 官方甚至從 0.16 版本開始便將其用於 TranslateC 模組，這顯示出用 Zig 處理 C 語言前端已具備實務上的可行性。

然而，討論的焦點很快轉向了作者在開發過程中的挫折感。部分留言者注意到作者在專案後期表現出對底層語言細節的疲乏，並最終選擇回歸 Rust。這引發了關於 Zig 與 Rust 抽象層級差異的辯論。支持者認為，Rust 雖然有嚴格的借用檢查機制，但其 RAII 模式與豐富的第三方函式庫隱藏了大量記憶體管理的複雜性；相比之下，Zig 強迫開發者必須深入思考分配器選擇、記憶體釋放時機以及數據結構的精確佈局。這種「手動感」對某些開發者來說是掌控力的體現，但對另一部分人而言，則可能演變成沉重的認知負擔。

此外，資深 Zig 開發者也針對作者的程式碼風格提出了技術性批評。有觀點認為，作者在處理數據結構（如集合交集運算）時感到挫折，部分原因在於尚未掌握 Zig 的設計哲學。例如，在 Zig 中頻繁分配臨時緩衝區而非原地修改數據，或是函數回傳值類型設計不當，都會導致記憶體管理變得混亂。這反映出 Zig 的學習曲線不僅在於語法，更在於如何適應其推崇的數據導向設計與所有權策略。當標準庫沒有提供現成的進階算子時，Zig 往往是在暗示開發者應尋求更高效的演算法，而非單純抱怨語言功能的缺失。

延伸閱讀

在討論中，社群成員特別推薦了 Aro (arocc) 專案，這是一個同樣由 Zig 撰寫、且完整度極高的 C 編譯器，目前已被整合至 Zig 的官方工具鏈中。此外，Nora Sandler 的《Writing a C Compiler》一書也被視為理解編譯器實作邏輯的重要參考資源。