編譯｜宇琪

策劃｜Tina

Zig 是一門試圖成為現代版 C 語言替代品的編程語言。相比 C，它希望在保持底層控制能力的同時，提供更好的內存安全能力。這個項目目前由一個非營利組織和一群開源貢獻者共同維護。

但在 AI 編程大熱的今天，他們選擇站到另一邊：Zig 已經明確禁止提交 AI 輔助生成的代碼。在 JetBrains 的一檔播客中，Zig 基金會主席 Andrew Kelley 對這類貢獻的評價非常不客氣：AI 輔助貢獻“幾乎總是垃圾”。

Kelley 說，有人給他們提交的貢獻“完全沒有價值”。更麻煩的是，這些貢獻不是零價值，而是負價值，因為它們會消耗維護團隊本就稀缺的代碼審查時間。Zig 的 pull request 數量已經超過了審查者能夠處理的范圍。錄制播客時，Kelley 提到，Zig 還有 200 個開放的 pull request，而這些 AI 生成的“垃圾貢獻”，只會讓整個團隊更慢。他說：“我們浪費了所有人的時間。”

這和大公司對 AI 寫代碼的態度形成了鮮明對比。過去一段時間，不少科技巨頭都在設定激進目標，宣稱公司內部已經有多少代碼由 AI 寫成，或者未來應該有多少代碼交給 AI。但 Zig 并不是一家背著效率指標狂奔的上市公司。Kelley 說，對 Zig 來說，“指導和培養”本身就是核心使命的一部分。因此，AI 貢獻不但沒有幫上忙，反而會破壞這個目標。他說：“我們都在努力成為更好的程序員。那些提交 AI pull request 的人，并沒有幫助這個目標。”

在這期節目中，Andrew Kelley 還詳細回顧了創建 Zig 的動機、非營利基金會的運營、對 AI 的強硬態度，以及為何堅持十年不發 1.0 版本。

本文基于該播客視頻整理，經 InfoQ 編輯。

核心觀點如下：

• 非營利組織作服務比用初創公司或大型企業更穩定，那些大公司總在追逐下一個目標，努力讓下季度利潤更高，而非營利只是想繼續做好它在做的事。

• 如果要我界定“只接受好的 AI PR”，那我還得去當裁判。如果一刀切地什么都不要，執行起來非常簡單。

• 任何 C 能做到的事情，Zig 都能做到，而且做得更好，少了很多 Footgun，出了問題也更容易調試。甚至可以說，Zig 擁抱 C 的程度勝過了 C 自己擁抱自己。

• 委員會或更民主的流程出于合作的意圖更傾向于找出妥協，我承認這有社會性上的好處，但代價就是難以保持項目的連貫愿景。

• 如果你在一家沒有靈魂的大公司，那就別再拼了，下午五點就回家，干點別的，不用那么使勁。

為什么構造 Zig？

Vitaly：我們已經有 C、C++、Rust、Go ，你為什么決定做 Zig？

Andrew：有意思的是，你列出的這幾種語言，恰恰就是我剛開始做 Zig 之前，用來構建數字音頻工作站的幾個語言。每換一種語言，我都會撞上一堵看似無法逾越的墻。最后我得出結論：不是我有技術短板，是語言本身有問題。就是在那之后，我萌生了創造一門新語言的狂妄想法。

我先試著在瀏覽器里用 JavaScript 做，但很快就發現層次太高了，我根本觸碰不到能讓這款音頻工作站提供一流用戶體驗的底層能力。于是我直接扔掉這條路，投入原生編譯語言。

接著我試了 Go。Go 的問題有兩個：一，想調用現有的 C 庫來創建窗口、按鈕什么的，體驗非常糟糕；二，垃圾回收器的問題。做音頻處理有一個硬實時截止時間，如果你不能在精確的時間窗口內處理完，就會產生雜音或卡頓，這對現場演出軟件來說絕對無法接受。所以 Go 也出局了。

然后我轉向 Rust，那時 Rust 還沒到 1.0。我拼命地寫代碼想要滿足 Rust 的規則，可一旦勉強滿足了，哪怕做一點點小改動，都會引發一連串編譯錯誤，徹底阻斷進展。我記得花了整整一個月去折騰字體渲染，結果卡在那兒寸步難行，沮喪得不行，就放棄了 Rust，換到了 C++。

用 C++ 一開始確實感覺效率高多了。但很快，一個小小的拼寫錯誤，一個不起眼的失誤，就會造成內存破壞 bug，讓我一調就是好幾周。這種反復出現的小錯誤以周為單位吞噬我的時間，對于這么大難度的項目來說，實在太慢了。之后我甚至試過“C 風格的 C++”，就是用 C++ 編譯器編譯，但鏈接時用 C 鏈接器，一旦使用花哨的 C++ 特性就報錯。即便這樣，還是動輒傷到自己。就在那時，我對自己說：我可以做得更好。比 C++ 好，比 Rust 好，比 Go 好，比 JavaScript 好，比 D 語言好。這就是我的狂妄。

Vitaly：現在 Zig 用來做什么？它解決什么問題？

Andrew：當你想完全掌控計算機，不想留下任何性能尾巴，要榨取最佳性能和最低內存占用，最終打磨出引人入勝的用戶體驗時，就會用 Zig。就在開始 Zig 之前，我為自己確立了一條新哲學：不再在用戶體驗上妥協。我再也不會說“因為我用 Go，所以我得接受這個限制”。如果為了交付最好的體驗必須更換工具鏈，我就換，哪怕自己創造一個。

對我來說，這在當時是一種完全不同的編程思維方式：不是我手頭的工具鏈能做什么，而是這臺計算機從根本上能做什么，我又如何用一切可能的工具鏈，甚至自己造一個，去做到這件事。

Vitaly：Zig 在生產環境里具體用在哪里？

Andrew：眼前一個很好的例子是 Ghostty。這是 Mitchell Hashimoto 做的終端模擬器，代碼質量非常高，Mitchell 在社區治理和模糊測試上都做得特別到位。

還有 TigerBeetle，一個用 Zig 寫的金融交易數據庫。他們把操作批量組合，達到了行業內罕見的效率水平。別的方案可能在 PostgreSQL 之上搭 OLTP，而他們打造了專用數據庫，比那種策略快上上千倍。這個項目特別注重預分配資源，一旦啟動，就預先分配好未來要用到的所有內存，此后永不再進行任何動態分配，這就讓延遲變得非常可預測、非常一致。這個場景恰恰說明了 Zig 的優勢：你可以在低延遲、可預測延遲和類似垃圾收集的高吞吐之間做出選擇。

Vitaly：Bun 呢？

Andrew：Bun 是一個 JavaScript 引擎，使用了 JavaScriptCore 和一堆 C++ 庫，而所有膠水代碼都用 Zig 寫成。這個項目最近應該是賣給了 Anthropic，我們也因此看到越來越多人開始用 Zig 做 AI。

Vitaly：我還聽說 Uber 在用 Zig。

Andrew：對，Uber 在用 Zig 的工具鏈。他們用 zig cc 來交叉編譯 ARM64 的項目，而且是與 Go 搭配使用。他們有一堆 Go 代碼，Go 本身的交叉編譯沒問題，但如果 Go 代碼還依賴 C 代碼，原生工具就搞不定了。你只要把 Zig 當作 Go 的 C 編譯器來用，就能連 C 依賴一起交叉編譯。

Vitaly：為什么叫 Zig？

Andrew：我想要一個短詞，搜“編程語言”時谷歌結果為零。我用 Python 腳本隨機生成了些詞，Zig 一下子就抓住了我，就選了。

Vitaly：Zig 在最受欽慕的語言里排前五，可十年過去了，還沒有 1.0 release，是什么在拖住它？

Andrew：1.0 對不同項目意義不同：Go 標記 1.0 后很長時間基本不再動語言。Rust 很早標記了 1.0，但有“版本”機制，在保持向后兼容的同時仍然可以大幅改變語言。寫現代 Rust 和當年 1.0 時的 Rust 已經很不一樣了。所以 1.0 到底是什么？本質上是一個向后兼容的承諾。

Zig 軟件基金會不是一家創業公司，我們沒有投資款，沒有投資人盯著我們。我們是一個 501(c)(3) 非營利組織，我們不需要燒光錢倒閉，不需要被收購，不存在退出計劃。我們的計劃就是做出一個偉大的項目，并在很長時間里持續改進它，我們有時間穩步前進。我們是一個非常精簡高效的小組織，不太燒錢，所以我們會一直在這里，持續改進 Zig 直到抵達那里，而不必過早地鎖死版本。等我們標記 1.0，它將是真正不妥協的心血結晶，我們不會被迫倉促鎖定任何糟糕的決策。

Vitaly：軟件圈有個概念叫“worse is better（更差就是更好）”，就是快速發布、以后再修。PHP、Go 都這么干成了。你卻選擇了完全相反的路。為什么？

Andrew：這個說法是我的一個雷區，語言學上它根本講不通。我覺得不如說成“用更少做更少”和“用更多做更多”，而 Zig 是第三種選擇：我們在嘗試用更少做更多。我們仍然想提供卓越的東西，想找到那種一丁點復雜性就能釋放巨大效用的甜蜜點。你看語言中的編譯期功能，小復雜度、大產出；再看工具鏈，只用一個 flag 就能讓編譯器把代碼瞄準差異巨大的操作系統和架構，而且直接能用。

Vitaly：你覺得沒有 1.0 會傷害到用戶或者企業的采用嗎？

Andrew：毫無疑問，一旦標定 1.0，我們會看到采納量激增。但我把眼光放在長遠未來，我想讓 Zig 成為未來 50 年的語言。我們已經開始在即將到來的 0.16 版本中看到這種長期投入的回報了。

Vitaly：能分享一個截止日期嗎？

Andrew：我們把它變成一場比賽吧，看是你上傳這個視頻快，還是我 0.16 版本上線快。

67 萬美元總收入

Vitaly：為了開發這門語言，你成立了 Zig 軟件基金會。2024 年的總收入是 67 萬美元。主要贊助方都有誰？

Andrew：在我們公布的博文里有一張漂亮的餅狀圖。讓我自豪的是那張圖的多樣化，大量贊助來自個人捐贈者，此外還有不少來自不同公司的捐款組合。沒有任何單一實體能對我們說：“嘿，你得做這個、做那個。”我們可以面對任何一個贊助者說：“對不起，我們不會照你說的做。如果你把錢拿回去，我們也能活。”這是一種非常互利的合作關系，跟商業組織之間設有健康的邊界線。

Vitaly：贊助方有誰能影響 Zig 的開發嗎？

Andrew：影響的方式和其他任何人完全一樣。他們可以在缺陷追蹤器上參與，可以發拉取請求，可以在開發頻道里聊天。最終就是人和人之間的交流，他們沒有秘密切高端渠道。在這里，每個人都在同一水平線上。

Vitaly：你的薪水是每年 15.4 萬美元，這和一名高級工程師差不多，可你是在構建整個語言生態，你自己的薪資是怎么定出來的？

Andrew：這是 Zig 軟件基金會首次董事會時定下來的，取的是當時紐約市（非營利成立地）中級高級軟件工程師的薪酬中位數。你的問題好像在暗示我或許值得拿更多錢，但說實話，我感覺自己就是個上層中產，我拿到的錢很多了，買菜輕松，在俄勒岡波特蘭還房貸也沒問題。我很舒服，不需要更多。

對我而言，經營一個精益、穩固、能夠在今天這種混亂金融環境里站得住腳的非營利組織的這種自主權，遠勝過再多一些零花錢。正是這一點讓我們能夠說：不，再等等。我們需要為 1.0 再留出一點時間。也讓我們在到處大規模裁員的那一年，還能給我們的合同工漲工資。對此我很驕傲，我們是一個健康的組織，這種滿足感是再多收入也填不滿的。

Vitaly：如果一家大公司無條件向 Zig 提供 1 億美元，你會接受嗎？

Andrew：放到背景下來看，我們每年的總收入從來都不到 100 萬美元，今年或許開始接近了。面對這筆錢，我有兩個限制條件。第一個是基金會的可持續性。我不想拿了這筆錢之后，花掉其中一大部分，以至于將來還得再找同樣量級的錢。那樣就成了依賴，而不是驚喜禮物。

第二個限制是團隊規模。我現在管理一個五人的團隊，我不認為我有能力管比這多太多的人，也沒這個動力，我肯定不會拿了錢就膨脹成管理一百個員工的角色。不過我能做的是：如果真有 1 億美元，我可以把它存進銀行，然后 100 年都不用再募資。所以，我當然會接受這筆錢，但絕不擴大規模。

這個問題本質上在問：如果有機會，我們會不會擴張？我想答案是稍微擴張一點兒。我可能會把團隊開到超過 5 個人，但超過 10 個就有點勉強了。

Vitaly：所以團隊是五個人，你的薪水就是基金會所有的開銷嗎？

Andrew：基金會只有我一名正式雇員，另外有一些合同工，總共大約五位是全職投入的。去年 91% 的款項都直接付給了投入項目的合同工，也就是說，我們收到的捐款絕大部分都直接轉化為了對 Zig 項目的開發付出。

Vitaly：在金錢上如此公開透明，是因為非營利的法律義務，還是對你個人來說也很重要？

Andrew：非營利確實有一些義務。我們是在美國注冊的 501(c)(3)，我借這個機會說明一下它和 501(c)(6) 的區別。501(c)(6) 是商業聯盟，Rust 基金會就是這種。像亞馬遜、Netflix、微軟、Meta，它們對 Rust 的成功有共同利益，所以都向這個 501(c)(6) 捐款，這樣它就能幫他們游說政府之類。

501(c)(3) 不允許去游說政府，也不存在別的企業利益，只服務于它的使命本身。我們在博文里分解收入和支出、分享細節，這是自愿的透明。但這也是一種營銷，因為我們在這些指標上做得不錯，可以增強人們的信心，證明我們干得不錯，同時也是一次籌款機會。

Vitaly：2022 年，你們離開了 Reddit 和 Twitter。為什么？

Andrew：我覺得在這些網站上發內容，已經越來越像在 Slashdot 或 Digg 上發東西了，它們正變得越來越無關緊要。我們是軟件工程師，想做盡可能少的營銷，這些東西已經不再給我們帶來相應回報了。我們開始做更多線下活動，比如 Zig Day，而不是依賴那些被算法控制、還要跟噴子打交道的社交媒體，這是我們現在認為更好的社區增長投資方向。

Vitaly：到 2025 年末，你又進一步把 Zig 主倉庫從 GitHub 遷到了 Codeberg，為什么？

Andrew：GitHub 對我們來說直接罷工了，我們的持續集成運行結果再也出不來。于是我們遷到 Codeberg，CI 服務器一下子就恢復正常了。

Vitaly：但你們在 GitHub 上有贊助者，他們跟過來了嗎？

Andrew：離開那些贊助渠道是一個艱難的決定。任何涉及資金的事情，失去一個收入來源總有點令人心驚。但歸根結底，我們是來寫軟件的，如果 CI 服務器不能工作，就必須去找好用的，這是最高優先級。

Vitaly：基金會因此損失了錢嗎？

Andrew：在資金方面我們完全沒問題。我們產出的是 MIT 許可的軟件，可以說是一場無附帶條件、面向軟件世界的捐贈。而為這個項目捐款的人，同樣也是無附帶條件的贈予。在這種關系下，我發現雙方對彼此都懷有很高的尊重。如果有人停止捐贈，我絕不會說：“你這混蛋，怎么不捐了？”當然不會，這本來就是無附帶條件的。同樣，當我們決定遷出 GitHub 時，我發現人們都非常理解和寬容。

Vitaly：為什么是 Codeberg，而不是 GitLab 或自建服務器？

Andrew：Codeberg 基本就是 GitHub 的復制品，遷移起來很容易。同時 Codeberg 是一個德國非營利組織，我個人覺得用非營利組織作服務比用初創公司或大型企業更穩定，那些大公司總在追逐下一個目標，努力讓下季度利潤更高，而非營利只是想繼續做好它在做的事。我要的正是代碼鍛造平臺上的這種穩定，所以選了 Codeberg。

Vitaly：離開社交媒體，離開 GitHub，這些都在社區引發了巨大爭論。很多人說這會阻止 Zig 的成長，把它邊緣化成小眾語言。個人怎么看？

Andrew：代碼鍛造平臺并不是項目的營銷渠道。我不認為大家是通過 GitHub 或 Codeberg 發現 Zig 的，而是通過各種演講、見面會、YouTube 視頻，以及 Zig Day 線下聚會群，這些才是人們聽說一門語言的地方。我們用 Git 還是 Mercurial，缺陷追蹤器在哪里，這些影響的是開發語言本身的便利程度，根本不是營銷，所以我完全無法理解為何有人會覺得這是場受眾危機。

Vitaly：你們脫離了 LLVM，為什么？

Andrew：我玩一個叫《Killer Queen》的十人競技街機游戲，非常好玩，但開發者選擇用 Unity 的物理引擎。問題在于，這個物理引擎對競技玩法來說極其核心，哪怕微小的改動都會讓競技玩家完全覺得手感變化，技術也得重來。結果這些開發者連新版 Unity 都不能升級，因為即便修掉了 Bug，社區都會炸鍋。他們犯了一個錯誤：為自己的核心產品引入了一個外部依賴。

我認為這是一個關鍵洞見：要避免你的核心產品存在依賴。而 Zig 當初依賴了 LLVM，我們正在糾正這個錯誤。我把它看作是自行車上的輔助輪，我已經開發 Zig 十多年了，在編譯器方面比十年前懂得更多，現在可以把輔助輪摘掉，與 LLVM 正面競爭了。

正因擁有了自己的核心產品、消除了依賴，我們才能做以前做不到的事。例如，當我們使用自研的 x86 后端時，就有了增量編譯能力。對于百萬行的代碼庫，修改一次后，到新二進制就緒，只需要 50 毫秒甚至更少。這是 LLVM 根本不可能做到的，但借助我們自己的代碼，現在可以了。

所有 AI PR 都是垃圾

Vitaly：Zig 對 issue 和拉取請求有著嚴格的禁止 LLM、禁止 AI 政策。為什么？

Andrew：第一個理由，這些貢獻無一例外都是垃圾。人們提交上來的東西毫無價值，不僅無益，還有負價值，因為它們搶走了團隊極其有限的審查時間。我們有超過 200 個開放 PR 都在等著審核，我們努力不落下太多。可當開發團隊人數少而貢獻者眾多時，審核時間的瓶頸就永遠存在。那些粗制濫造的 AI 貢獻會吃掉我們的審核時間，幾輪來回后，我們發現對方根本不知道自己在干什么。他們只是把我們給的建議粘貼回對話里，再把對話“洗”一遍想掩蓋 AI 的痕跡，可我們還是看得出來。最終我們意識到這代碼永遠也達不到質量要求，因為他們一竅不通。結果大家都浪費了時間，那些耐心排隊的人沒被審到，代碼也合并不了。

我們把審核和貢獻的過程叫做“貢獻者撲克”。除了我們自己寫碼，接受貢獻的核心目的是傳幫帶。整個目標是讓貢獻者將來能成為一名核心成員，或者成為更有價值的貢獻者，這既有助于項目本身獲得能熟練貢獻的人手，也能豐富他們的履歷，讓他們成為更好的系統程序員。

我們的時間有限，所以要識別出：哪些人值得我們投入時間去幫助他們成長為更好的程序員、更好的貢獻者，哪些人只是一次性的路過，發個東西，然后消失。顯然使用 AI 的人永遠屬于第二類，根本不值得給這些人投資，他們學不到任何東西，以后也不可能加入核心團隊。

這個政策合情合理。Zig 本身也是一個教育項目，寫在我們的使命里：為學生提供指引和教育。我們都在學習，都在精進編程。發來 AI PR 的人，無助于這個目標，甚至可以說在損害它。所以對我們項目來說，嚴格的禁 AI 政策是恰如其分的。如果要我界定“只接受好的 AI PR”，那我還得去當裁判。如果一刀切地什么都不要，執行起來非常簡單。

Vitaly：你們怎么檢測 AI 生成的內容？容易嗎？

Andrew：并不總是很容易，我敢肯定有些已經混進來了。最近他們已經開始“洗”LLM 的文本了，不是直接復制粘貼那么明顯，而是試圖用自己的語氣重寫，或者試圖裝得更像人。我已經審查過太多 PR，慢慢就能察覺到這不是一個人在收到反饋后會做的反應，暴露后就很清楚了。但最近這勢頭太猛了，我猜我們可能得改變當前允許任何人來貢獻的策略，可能需要一個更強的過濾器，獲得權限后才能發送貢獻。

Vitaly：Zig 代碼用的是 MIT 許可，那是什么？是怎么用的？

Andrew：它幾乎等同于公共領域。幾乎什么用途都行，唯一的限制就是，你在復制代碼時必須附帶許可證文本，以及我們不能對任何問題負責。基本就是“沒有質保”。

Vitaly：這意味著任何人，包括大公司，都可以用你們的代碼去訓練 AI，但你自己禁止 AI 參與 Zig 貢獻。你怎么看待這一矛盾？

Andrew：是挺諷刺的，我個人對此沒有任何意見。我無比篤信 Zig 是獻給世界的零附加條件禮物。如果有人想拿 Zig 去做 AI 訓練，我不在乎，完全沒問題。我不喜歡那些公司做的某些事情，但這并不妨礙我樂見他們使用 Zig。Zig 被用得越多，就越證明它有價值。

Vitaly：坊間說法是，LLM 在處理 Zig 代碼時比 Python 或 JavaScript 困難。是這樣嗎？

Andrew：我自己沒怎么嘗試，但據我所知，其實沒啥問題。Mitchell Hashimoto 在用 Ghostty 時大量用 AI 輔助寫 Zig 代碼。另一個我知道的人，他做了一款讓 AI 更好支持 Zig 的工具，反饋說效果不錯。我見過有人說不行，也見過有人說完全沒問題。

Vitaly：我最近讀了你的帖子，你說“Vibe coding 相關的博客乏味至極，就像不是去看廚師做菜，而是讀餐館評價”。這是什么意思？你對 vibe coding 有怎樣的看法？

Andrew：我熱愛計算機，也很喜歡了解別人拿它做了什么。你讀一個人的項目分享，有時能感覺到神秘和魔法的味道：他花了很長時間，學到了教訓，作為程序員和計算機使用者的技能因此大增，最終實現了目標。讀到那樣的博文，會激活你的想象力，讓你思索自己能做什么，教給你東西，讓你和作者產生情感聯結。

但反過來，我們看到的是人們在說：“我試了這個版本的 Claude，或者那個版本的 OpenAI，有時它表現得出奇地好。”我一直聽人說 AI 寫的代碼出奇地好。可對我來說，這不是我想讓軟件去夠到的及格線，我想的是無懈可擊的完美。靠“發現沒有 bug”來驚喜，這個質量標桿太可怕了。你看到一大堆人在說：“我也說不清，我試著編了個應用，好像能跑。”好吧。這太沒意思了。

Vitaly：你自己試過 vibe coding 嗎？

Andrew：我和朋友 Richard Feldman 私下通過一次話，他給我展示了如何在 Zed 里用 vibe coding，我也試了一下，我覺得這項技術在根本上是挺有意思的。真正讓我反感的是，它被大概四家公司集中控制，它們對模型、對一切擁有絕對掌控。我總不能從用自己的電腦、自己的電來寫代碼，轉向跑到別人的計算機上、通過網絡使用閉源編程吧。還得按月付費，居然有人一個月花 300 美元來干這個。對我來說，這提議簡直瘋狂，我從來不愿意為了獲取任何 GenAI 的結果而放棄我所擁有的東西。

Vitaly：你對編程的未來怎么看？10 年、20 年后，人類還寫代碼嗎？

Andrew：人永遠不會停止寫代碼，因為寫代碼真的很有趣，它至少永遠是一種愛好。我敢說，我手機和電腦上用得最舒服的 APP，都是人們用業余時間出于愛好做出來的。那些公司讓我不得不用的東西，總讓我覺得自己跟它們之間有種敵對關系，它們總想賣我東西、推我廣告，或者用某種它們設定的用戶沉迷指標操控我。

可一旦用到一個愛好者寫出的 APP，那感覺就是：它尊重我，它把我當作計算機的老板。這才是我希望和軟件建立的關系，這種關系永遠不會消失。人們永遠會希望把做軟件當成一種愛好，永遠會想做自由開源軟件，永遠會想和他們的設備保持一種“我才是老板”的關系。無論那些大公司多努力想成為我們硬件的主人，這些都永遠不會消失。

Vitaly：你常批評臃腫軟件，那你真正景仰的三個軟件項目是什么？什么讓它們偉大？

Andrew：第一非 Linux 莫屬。也許很難想象一個沒有它的世界，但只有專有操作系統的世界肯定比有 Linux 的世界糟糕得多。Linux 對自由開源開發者來說無比重要，對經濟也是一大福音，各國各地的企業都能在 Linux 之上免費構建自己的業務。無論從理想主義還是從財政保守的角度看，它都非常好。

接下來是 Blender。因為它在專業領域得到了廣泛應用，作為一個開源項目，它和那些擁有大量資金、大量開發人力的公司在正面競爭，而且還在贏，它可是開源軟件。這太杰出了，而且它同樣是一個非營利組織。

第三是 VLC。VLC 也是非營利組織，我覺得那家非營利運作得相當棒。我大學剛畢業時向 FFmpeg（VLC 依賴的庫）提交過貢獻，而 VLC 的組織竟然為所有給 VLC 及其依賴庫做貢獻的人報銷參加 VideoLAN Dev Days 的旅費。當年我就是個毛頭小子，卻在那個非營利組織的資助下去了都柏林和巴黎參會，那經歷太棒了。

Vitaly：我們團隊注意你在直播時用 Firefox 瀏覽器，為什么是 Firefox？

Andrew：我對瀏覽器生態的匱乏感到很擔憂。微軟干掉 IE 后，現在只剩下 Chrome、Safari 和 Firefox。Chrome 占據了絕對主導的市場份額，我認為這對 Web 是個問題。說壟斷普遍有害應該沒什么爭議，瀏覽器壟斷對用戶來說比健康競爭要糟糕得多。

所以我最初只是因為它處在劣勢而選了 Firefox，也算為對抗 Chrome 壟斷出一點力。但我得說，最近我對 Mozilla 相當不滿。它雖然是非營利，可我覺得它成了那種飽含腐敗、其立場和用戶利益不一致的例子。這讓我特別沮喪，因為實在沒有別的替代方案：Chrome 是 Google 的，Safari 是蘋果的，然后就是這個似乎在失控墜落中的 Firefox。我真不知該怎么辦。也有一些新的瀏覽器項目在做，但在它們成氣候之前，我毫無頭緒。

比 C 更像 C，比 Rust 更簡單

Vitaly：Zig 有時被定位為 C 的替代者，但 C 無處不在：Linux 內核、嵌入式系統、700 萬開發者。什么讓 Zig 比 C 更好？

Andrew：Zig 更好，是因為它沒有放棄 C 提供的任何一種能力，同時改善了 C 的缺陷和弱點。之前那些試圖替代 C 的嘗試，總是不得不丟掉 C 的某些強項。拿 Go 舉例，Go 寫起服務端軟件非常舒服，標準庫里有 HTTP 什么的，但有一整類任務你永遠沒法用 Go 去做，而 C 可以。所以那是種取舍，為了換取 Go 的那些好特性，你不得不放棄一些東西，這就是 Go 成不了 C 替代者的原因。

而 Zig 什么都沒放棄。任何 C 能做到的事情，Zig 都能做到，而且做得更好，少了很多 Footgun，出了問題也更容易調試。甚至可以說，Zig 擁抱 C 的程度勝過了 C 自己擁抱自己。C 只為有符號整數提供優化，為無符號整數提供環繞語義，在 Zig 里這兩種你都可以有，你可以選擇環繞的無符號整數，也可以選擇“承諾絕不溢出”的無符號整數。這簡直是 C 語言上大剌剌缺失的特性，是 C 在能力上的不足，所以也許可以說 Zig 比 C 更像 C。

Vitaly：但真的可能替代 C 嗎？

Andrew：要替代 C，你就得在 C 自己的游戲里打敗它。你必須為人們提供一種處處可重用的代碼書寫方式：能在操作系統內核里跑，能在嵌入式設備上跑，能在視頻游戲里跑，能在 WebAssembly 里跑，這正是 C 長盛不衰的理由。如果我們提供這些特性，而且像 C 一樣變得無比穩定，人們就會做出正確的選擇，他們會選更好用的、能帶來更好性能、更少 bug 的工具，但他們永遠不會放棄 C 有的那些能力。這也是為什么我堅信 Zig 會在替代 C 上成功，因為我們沒有放棄 C 所擁有的任何一項能力。

Vitaly：Zig 和 Rust 有什么不同？

Andrew：Zig 和 Rust 最核心的不同在于類型系統（Type System）。Zig 是一門比 Rust 更簡單的語言，意思是類型系統里沒有一套用來描述“哪些類型能傳給哪些函數”的元語言。在 Rust 里，你寫函數帶參數，要聲明這個參數支持克隆，或者支持這個或那個接口，并且得把所有關于此參數的規則完整描述出來。Zig 沒有這套機制，你得傳一個具體類型或用類似 C++ 模板那樣的泛型方式，代碼會隨著你傳入的類型代換進去。這就是一個取舍，Rust 代碼里你能得到更多關于類型系統的保證，而 Zig 代碼里你讀到的代碼有著更強的簡單性。

但這之外還有一些更深層的差異，比如內存管理。Rust 把你引向一種和 C++ 很相似的、以 RAII 為中心的內存管理風格。對象有引用關系，引用計數，降到零時就析構。在 Rust 中，這自動發生，就像 C++ 中析構函數運行一樣，這就是你在 Rust 中管理內存的方式。

Zig 里，內存分配器則顯式得多。我們可以采用這種引用計數風格，但計數代碼得你自己顯式寫出來。而我們實際中更多會為應用量身挑選一種內存分配策略，比如用一個區域分配器把互相關聯的分配歸攏在一起，一把丟掉。Zig 的這種特性，就是你可以為極特殊的應用混合出不同方案。而我認為這種專注于優化內存布局的方式，更算是 Zig 的固有特性，而在 Rust 里，你更被綁定在那種面向對象的生命周期策略上。

Vitaly：那從技術領域上說呢？什么情況會選 Zig 而不是 Rust？

Andrew：當你想要對代碼到底在干什么有更強的掌控時，就選 Zig。在 Rust 里你總得力圖讓源碼匹配 Rust 組織、建模現實的那套方式，讓借用檢查器滿意，創建特性來滿足約束，力圖讓類型理論圓滿。而在 Zig 里，你會想：“我想讓 CPU 去做什么？”然后直接寫出讓 CPU 做那件事的代碼。如果你是后一種心態，Zig 會比 Rust 更自然地契合你的編程思維。

Vitaly：Zig 的殺手特性是什么？為什么？

Andrew：殺手特性是它的工具鏈。使用 Zig，你就在用一套對系統沒有任何依賴的軟件套件。它可以在你選擇的任何操作系統上運行，你也能瞄準任何操作系統編譯目標代碼，你做到了獨立于運行環境。

我常用一個衡量項目參與門檻的標準，叫作“README 檢測”，就是看這類代碼的 README 里貢獻步驟寫了什么。我要裝一堆系統包嗎？不同操作系統步驟有區別嗎？要輸入多少條命令才能搭出環境？需要 Docker 嗎？要特定硬件嗎？對我而言，黃金標準是：一行命令，一個依賴，對所有人在任何機器上都永遠可用。

當你使用 Zig 工具鏈時，這標準我們已經達到了。你去看一個 Zig 項目，README 里應當這樣寫——“構建：zig build”，完事。所有貢獻者要做的，僅僅是zig build，它永遠都能用。

Vitaly：很多人爭論 Zig 對未使用變量過于嚴苛，直接當成編譯錯誤。為什么這么處理？

Andrew：這類抱怨，往往在一個人不得不去重構大量代碼時當場反轉。核心原因是它節省時間，那個錯誤真實地替你捉住了 bug，那些 bug 特別難找，而你加上一個丟棄標注所花費的時間卻極少。

而且歸功于編輯器支持（特別要感謝 ZLS 團隊實現了這一點），你可以在編輯器里開啟一個設置，自動幫你在未使用變量上加上這些標注。也就是說，你如果不用，它幫你加上丟棄標記；你后面再用了，它自動把標記移除。你可能覺得這折騰半天只是消滅一個錯誤有什么意義？意義就在于，兩個合作寫同一段代碼的人可以各取所需：希望看到這類錯誤的人可以取消勾選 IDE 里的這個設置，而覺得煩的人可以勾選。后一個人不必再為報錯煩心，前一個人照舊接收錯誤提示，雙方共同編輯同一份代碼。在源碼庫里，標注始終存在，所有人都贏。

Vitaly：有些開發者對新 I/O 接口感到吃力。是它過于復雜，還是只是不同？

Andrew：我認為我在這里找到了一個最優解。I/O 流的目的是抽象，是要一次寫代碼，到處可重用。也許你在寫一個圖片加載庫，或是序列化到某種數據格式的代碼，這時候就需要接收一個 reader 或 writer 參數，讓邏輯保持不變地放進一個個包里，用到不同應用里，這就是它的目的。

問題在于，一旦你在抽象層下面做讀寫操作，編譯器往往很難窺見背后的邏輯并執行優化。我的這個最優解就是：這個接口本身內帶 buffer，這樣既幫助編譯器產出好的機器碼，又仍然允許使用者達成可重用的主要目標。

我認為用這套接口是簡單的，但要去實現這個接口會難一些。但我要說，這復雜度不是意外，而是此性能與可重用性二者交匯點自然催生的復雜度，它意味著實現就必須是這個樣子。如果我能把它變得更簡單我早做了，但這就是我們在 Zig 里寫出既能讓計算機按你心意去跑、又具有可重用性代碼的唯一方式，這是我們的優先級順序。

如何學習 Zig？

Vitaly：Zig 有這么多獨特特性，最好的學習方式是什么？

Andrew：我強烈推薦初學者去試試 Zigglings。它提供了一系列練習，每段代碼幾乎能跑但偏偏總有個問題，你的任務就是修復那個程序，從而學會一項新的語言特性。做完這些練習，你便學會了整門語言。

Vitaly：如果已經會 C，轉過來是否容易？還是二者思維完全不同？

Andrew：我認為 C 到 Zig 的過渡特別順滑。你在 C 里能做的一切，在 Zig 里都能做，還少了很多坑。舉個例子：在 C 里你遇到 segmentation fault，你只會看到這幾個字，沒別的 output 了。而在 Zig 里，你會得到一份完整的棧追蹤，精確指向出錯時你所在的每一行代碼。所以 C 程序員來到 Zig 后會感到自己所有技能無縫轉移，然后突然發現自己犯的錯少了，debug 容易了，效率飆升。

Vitaly：各大論壇有個辯論：該不該把 Zig 作為第一門編程語言來學？你怎么看？

Andrew：我覺得這真的因人而異。有些人傾向于函數式思維，特別想最先把 Lisp 學了。但我確實認為，如果要學計算機本身是如何運作的，Zig 是一門很好的語言。你會學到 CPU，會學到內存，你在 Zig 里獲得的任何技能也都能遷移到其他語言里。你學到的不是“Zig 沒有 borrow checker”之類的 Zig 規矩，你學到的是計算機規矩。這些信息對初學者也同樣珍貴，即便他們后來放棄了，決定轉向更高層的語言。

Vitaly：你個人寫 Zig 用什么工具？

Andrew：因為我經常做破壞性變更，我的方案并不怎么高科技，就是終端加上 Vim。Vim 極具彈性，就算我改了語言語法，代碼照樣能編輯。其他一些高級貨色比如 Tree-sitter 或者語言服務器，需要穩定的語法樹或者穩定的語言，我一做破壞就容易崩，所以我需要一套對這些動蕩有極強適應力的環境。

我必須向 ZLS 團隊致敬，他們在人們需要一個語言服務器的空白地帶做得非常出色，而我們官方目前還沒提供這個。

Vitaly：ZLS 是什么？

Andrew：ZLS 是 Zig Language Server 的縮寫，就是實現了語言服務器協議的第三方項目，不屬于 Zig 軟件基金會，那些貢獻者純粹是憑自己的意愿做這一切。如果你喜歡他們的工作，可以去他們主頁看看，考慮捐點款什么的。

Vitaly：Zig 官網也推薦了不少 JetBrains 產品，你自己用過嗎？

Andrew：我從沒用過 JetBrains 的產品，因為它們是閉源的。

Vitaly：你希望像 CLion 或 VS Code 這類工具在 Zig 的支持上還能做什么？

Andrew：很久以前見識過 JetBrains 或 Eclipse 對 Java 做的高階重構工具，像“提取函數”、“重排函數參數”、“全局重命名”之類的，手工改非常耗時，但借助類型和語法信息計算機能做得絕對準確、瞬間完成。那真的很棒，這也是我以后想加進我個人工作流的東西，取代我現在用的 Vim 宏或 Zed。

我甚至想象過一種更復雜的重構工具，幾乎像是用于基于類型信息做大規模變更的查詢語言，讓你能信心十足地提交出上萬行的 diff，因為每個變化都經過“類型匹配”的驗證。這些效率特性是我的夢想。

Vitaly：有人會說 AI Agent 能幫你解決這個。

Andrew：可那樣一來我還得檢查它做出來的東西。假如我的任務是“重命名一個變量”。如果我用的工具能做到絕對的確定性，我點下去，生成一個提交，再也不需要去看，100% 相信它正確。可要是讓 AI 去做同樣的事情，我還得一行一行審查，效率反而遠不如專門的工具。

Vitaly：你的信仰：終身仁慈獨裁者（Benevolent Dictator for Life，BDFL），能解釋一下嗎？

Andrew：挺逗的，每次我橫穿馬路走在巴士前面時都會想到這個。軟件項目通常要在等級制和某種民主流程之間做選擇，很多項目選擇等級制，因為它更簡單，不會有權斗，也不用通過投票來對改動建立共識。民主很難，因此很多項目默認采用 BDFL 風格，當只有一個人在維護時，這就是默認狀態。除非你刻意引入更民主的流程，否則自然就得到 BDFL。

Vitaly：為什么一個獨裁者比像 C++ 那樣的委員會更適合語言設計？

Andrew：這里存在一個取舍。如果只有一人掌控，他必須努力去理解一切、擁有一套融貫的愿景。而委員會可能出現多人各自持有無可調和的合理需求，這些需求都是有效的，但項目的單一路線無法同時滿足它們。一旦妥協，往往得到的是比“讓某一方勝出、某一方落敗”的更差的產品。委員會或更民主的流程出于合作的意圖更傾向于找出妥協，我承認這有社會性上的好處，但代價就是難以保持項目的連貫愿景。

Vitaly：你不覺得這模式有風險嗎？今天的 Zig 就是你。要是你明天離開怎么辦？

Andrew：從軟件工程的角度，我覺得沒問題，我的同事們都非常有才華，完全可以接過運營。但從政治和組織角度，我的工作還沒做完。因為如果我放開 BDFL 的控制，項目就會因跟金錢接觸而生銹。一旦金錢流入系統，系統就會遭腐蝕。強有力的層級領導只有在一個想要抗拒這些影響的首腦下，才能擋住它。如果你著手建立民主過程，金錢就會腐蝕它。

但我同樣認為一人老大不是長久之計。遲早我要退休，遲早想做別的事。你看歐洲歷史，良君時代君主制不錯，可繼承人是個糟糕領導者的話，一切全完，所以這不可持續。長遠可持續需要民主，真正的挑戰在于設計一套民主，讓它不至于隨時間被金錢的力量腐化。

“Zig 是一座獻給計算機的圣殿”

Vitaly：做 Zig 超過十年了，什么在驅動你堅持下去？

Andrew：我熱愛我的工作。每天早上醒來，我都為投入 Zig 而興奮。對我來說，Zig 項目有點像一座獻給計算機的圣殿。我愛計算機，我要讓計算機服務于人。Zig 是我獻給世界的一件樂觀主義禮物：一門偉大的編程語言和工具鏈最終會帶來這種結果，我信任人類同胞會用這個工具去承擔這項任務。取悅用戶，做出能創造動人體驗的軟件，這太讓人滿足了。就像表演一樣，就像音樂家從舞臺上得到的那種感覺，我做軟件也能體會到。

Vitaly：這過程中最難的部分是什么？

Andrew：稅。開玩笑的。是非營利組織那套文書工作，它完全必要，要合法合規，要接受大額捐贈，總得有人干，如今這個人就是我。沒人喜歡文書工作，有些日子我捏著鼻子做會計，有些好日子我能編程。

Vitaly：那在真正編碼時有沒有什么難的？

Andrew：做改動時，更新代碼有時要花費很久，比如我們前面聊的在 0.15 版帶出的 I/O reader、writer 的變更。最開始為接口工作很過癮，我找到了最優解，設計出了 API，測試、跑通，發現了在其他語言中前所未有的解法。然后我花了接下來整整六個月修正標準庫和生態里的項目，把本來工作的代碼重寫成使用新接口。換句話說，我讓用戶承受的痛苦，自己也得在標準庫里再受一遍。那段漫長的苦旅需要意志力支撐，有些日子必須凝聚力量才能繼續。但我挺過來了，所以我們走到了今天。但這些大變更，確實需要意志力和決心才能收尾。

Vitaly：你作為程序員或領導者，有過倦怠嗎？

Andrew：我覺得倦怠發生，往往因為投入巨大卻看不見相應回報。我和倦怠絕緣，很重要的原因是我在巨量付出之余，一直在收獲回報。我確實見到開心的用戶，每做一個 Zig 發布版，看著剛寫完的發版說明，看到我們做出的所有改進，滿足感就來了。

有時回報會延遲，就像那次 I/O 大變更，代碼一改就是好幾個月，回報要等等才來，那種感覺確實有點像倦怠。但回報終究到來，我又好起來了。所以很大程度上，倦怠與我無緣，因為我的工作帶來極高的滿意感。

Vitaly：對那些掙扎在倦怠里的人，你有什么建議？如果你要輔導一個人，會聊這個嗎？

Andrew：我會先說，別忘鍛煉，好好睡覺，吃得健康，這些因素累加起來力量巨大。先把這幾項做到，問題說不定就沒了。

如果沿著判斷分支往下走，我覺得很多人的工作本身就不令人滿足。如果你討厭手頭的事，覺得你的公司對世界沒有價值，還必須拼命干，這就是倦怠的來源。這時你有兩個選擇：要么去艱難地換一份工作，或者嘗試創業，給自己創造一個新工作，那會非常辛苦；要么你就在現在這家公司里摸魚，不再那么賣力。我們都不太愿意承認后者是好辦法，如果你動力和能量還在，盡量選前者。不過說真的，如果你在一家沒有靈魂的大公司，那就別再拼了，下午五點就回家，干點別的，不用那么使勁。這是我給倦怠者的建議。

Vitaly：對 Zig 來說，什么算是成功？

Andrew：我覺得有兩種回答。某種角度說，成功已經達到了，因為我們擁有多元化的收入流，在財務上獨立于任何單一實體。我們已經有了開心的、持續使用 Zig 的用戶。我們也在持續改進 Zig，每年大約發兩個版本，這是可持續的，我們不用改變航道，這已經良好了。從另一種角度看，我的確希望看到更大的采用量。一個衡量成功的標準是，達到 Go 或 Rust 級別的廣泛采用。

Vitaly：商業采用對你來說重要嗎？

Andrew：商業采用能幫我們從企業捐款中獲取資金，我們需要謹慎保持多樣性，但它仍然非常有用，所以我不會忽視。而且，做出一樣普遍有用的東西，它天然就會被企業廣泛采用。現在就有那么多人在用 Zig 搞 AI，就很說明問題：如果你做出有價值的東西，人們就用它。即便我覺得某些人 vibe coding 出的項目無聊，一門語言被用來緊跟當代流行事物，本身也是它有用的一重證明。

Vitaly：如果能回到 2015 年，你還會啟動 Zig 嗎？

Andrew：絕對會。我辭掉 OkCupid 工作、全職投入 Zig 的那一天，就人生軌跡而言，是我生命中最棒的一天。我無比慶幸自己做了這個選擇，它給了我一種深沉的充實感、獨立感，以及對自我價值的重估，我看待自己和社會貢獻的眼光都不一樣了。

我覺得我基本上不適宜被別人雇傭，還好在職場上從來沒人發現。我只有做自己的老板才能快樂，一旦能夠這樣，我就真正快樂了，就像現在。

訪談原鏈接：

https://www.youtube.com/watch?v=iqddnwKF8HQ&t=1s#

聲明：本文為 InfoQ 編譯，不代表平臺觀點，未經許可禁止轉載。

會議推薦

企業級 Agent 落地，繞不開 4 個真實的工程問題。如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統才能真正理解上下文？如何通過算法壓榨實現智力增量與成本控制的極致平衡？多 Agent 協作，如何做到可觀測、可治理、可控制？6 月 26-27 日，AICon 全球人工智能開發與應用大會·上海站國內頭部公司的 Agent 實踐，一次說透。