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 的那一天，就人生轨迹而言，是我生命中最棒的一天。我无比庆幸自己做了这个选择，它给了我一种深沉的充实感、独立感，以及对自我价值的重估，我看待自己和社会贡献的眼光都不一样了。
我觉得我基本上不适宜被别人雇佣，还好在职场上从来没人发现。我只有做自己的老板才能快乐，一旦能够这样，我就真正快乐了，就像现在。
