Zig 项目为何正走向死胡同

Zig 作为一门编程语言在不断进步。不幸的是，其管理层似乎越来越决心让它成为那些真正想使用它的人眼中的糟糕选择。

Zig 是一门引人入胜的编程语言。它的设计中包含着真正优秀的理念，其技术雄心令人印象深刻，并且它吸引了一批才华横溢的开发者，他们花费数年时间构建了一套严肃的系统编程工具链。然而尽管如此，推荐它正变得越来越难。

问题在于 Zig 似乎管理不善。

在过去一年里，该项目做出了一系列决定，单独来看，这些决定可能只是关于开源开发的普通分歧，但合在一起，却揭示出一种令人深感担忧的模式。

这门语言持续破坏兼容性，却没有对稳定性做出具体承诺。它的贡献政策排除了其他方面完全合理的工程工作流程。它最著名的用户之一放弃了这门语言，却遭到了公开的敌意。它从 GitHub 迁走的举动，用一个规模更小、未经充分验证且饱受可靠性问题困扰的服务，取代了一个成熟的开发平台，而该服务的运营者越来越将自身的哲学偏好强加于托管项目之上。

反复出现的主题是，Zig 的维护者似乎更热衷于推行他们关于软件应如何开发的愿景，而不是让 Zig 成为想要构建软件的人们的实用工具。对于一门编程语言来说，这是一个严重的问题。

Zig 永远处于未完成状态，而其用户为此付出代价

Zig 的开发已持续十多年。它仍停留在 0.x 版本，没有稳定 1.0 发布的确定日期。

漫长的开发周期或低于 1.0 的版本号本身并没有错。许多有用的软件都在所谓的 0ver 下运行。esbuild 就是一个突出的例子，尽管其主版本号仍为 0，却有着坚如磐石、毫不妥协的质量，且几乎没有破坏性变更。

但 Zig 是一门编程语言，不是打包器。

编程语言是基础设施。开发者针对其语法、标准库、编译器和构建工具编写应用程序和库，而这些接口决定了周边生态系统在从一个版本到下一个版本之间还能保留多少可用性。在 Zig 中，它们似乎永远在变化，作者们几乎痴迷于破坏性变更。

看看 0.15.1 发布说明，其中对 I/O 接口和标准库做了大量更改，包括被亲切地命名为“Writergate”的改动。如果你是编写编译器的人，这足够有趣；但如果你是那个代码再也无法编译的人，想必就没那么有趣了。0.16 版本延续了这一转变，而于 2026 年 10 月发布的 0.17.0 又对语言及其工具链带来了进一步更改。几乎可以说，Zig 的维护者享受破坏兼容性；如果不是这样，他们至少对此习以为常。

因此，升级 Zig 往往不仅仅是安装一个新编译器。它通常意味着重写现有代码的很大一部分、更新依赖项，并等待工具和库跟上。Zig 公开记录这些更改的事实，并不能减轻负担。

这些改动中有些可能会、也可能不会改善设计；但这并非重点。每一项改动都会给所有已经在该语言之上构建了东西的人带来额外工作。十多年过去了，问一句这种状况何时停止、我们何时才能认真开始编写 Zig 代码¹，是完全合理的。

维护者有一份通往 1.0 的路线图，但这并没有给开发者任何有意义的指示，说明他们何时才能指望所依赖的接口停止变动。很可能还要再等十年。

这就让他们面临一个选择：把项目冻结在旧编译器版本上，或者反复投入工程精力去跟上上游。当一个项目给你两个糟糕的选择时，你就知道事情不太妙了。

一门编程语言不可能永远停留在实验阶段而不承担后果。到了某个节点，实验就不再是好处，而开始成为所有使用该语言的人的负担。而在现阶段，我们早已远远越过了那个节点。

Zig 的不稳定不仅仅是一种不便。它是这门语言难以被依赖的核心原因之一。

而且这让维护者对贡献者的态度变得相当难以辩护。

一个想给你上课、而不是接受你代码的项目

Zig 有一项极其严格的AI 贡献政策。

不允许 AI 生成的代码。不允许 AI 辅助编辑。不允许 AI 辅助翻译。不允许与 LLM 头脑风暴后再分享结果。甚至不允许用 LLM 找 bug。真的吗？

把一千行未经审查的 AI 垃圾塞进一个拉取请求，与用助手去理解编译器某个不熟悉的部分、可能发现一个 bug，或帮助实现一个修复，这两者之间有显而易见的区别。而 Zig 的政策在区分这两者方面做得实在少得可怜。

在贡献者扑克与 Zig 的 AI 禁令一文中，维护者解释了他们的理念。他们想投资于那些会深入理解 Zig 并长期参与的贡献者。审查低质量的拉取请求成本高昂，而 AI 据称让这个问题变得更糟。

说得有道理。没人想审查垃圾。但接下来是耐人寻味的部分：

“你赌的是人，不是牌。”

文章主张，投资于合适的贡献者比其第一个拉取请求的内容更重要。它甚至承认存在有能力的 AI 辅助贡献者，但认为与不使用这些工具的人相比，他们是不具吸引力的赌注。

让我们想想这意味着什么：一项有用的贡献可以（在 Zig 的情况下，实际上必须）被拒绝，不是因为它不正确、测试不充分或不可维护，而是因为其作者用了错误的工具来产出它。项目不再只评判贡献本身。它在评判贡献者的开发过程。仅凭功绩已经不够了。

而且显然，贡献者被期望深入熟悉 Zig 的内部实现，才能获得修复某个东西的特权。为什么？

不是每个人都想成为编译器工程师。有些人在构建自己的软件时遇到一个 bug，只是想把它修好。无论你打算在未来十年为 Zig 工作，还是再也不碰它，这都是完全正当的贡献。

真正荒谬的地方在于，这种态度与 Zig 永久性的不稳定之间存在着多么尖锐的冲突。语言本身、标准库、构建系统都在不断变化。开发者不得不学习新的接口、迁移他们的项目、更新依赖，然后等到下一个版本发布时，再把这一切重来一遍。

而在强加这种持续不断的重新学习任务的同时，Zig 的维护者们却认定，某些本可以让这件事变得更容易的工具是不可接受的。

你必须理解这门语言。你必须跟上它的变化。你必须学习它的内部实现。而且你最好按照被认可的方式来。从什么时候开始，维护你的 Zig 代码不再算是软件开发，而变成了 Zig 项目布置的作业？

这又如何对得起 Zig 自己的承诺——“专注于调试你的应用程序，而不是调试你对编程语言的知识”？

我最初对 Zig 产生兴趣，恰恰就是因为那个承诺。每当我看到 Rust 代码时，我都觉得自己需要一个博士学位才能看懂。Zig 则直截了当、易于理解。那是在他们爱上为破坏而破坏的很久之前。

大多数开发者使用编程语言，并不是因为他们想和编译器的维护者建立一种持续的教育关系。他们只是想用合适的工具把事做完。

要求贡献者理解并支持自己的工作，这完全合理。但规定并指定他们该如何获得这种理解，就远没有那么合理了。一项编译器的改进不会因为有大语言模型参与产出就变得毫无价值。以此为由拒绝有用的工作，并不是技术严谨。

那是教条。

Bun 离开了 Zig。而 Zig 的回应令人难堪。

多年来，Bun 实际上就是 Zig 的免费广告。一个用 Zig 编写的高性能 JavaScript 运行时，获得了大量采用，并证明这门语言可以用于严肃的生产软件。Bun 自豪地高举着 Zig 的旗帜。即便 Zig 越来越深地滑入永久破坏的深渊，Bun 依然把 Zig 当作重要的 1甚至如此。

然后，在 2026 年 7 月，Bun 宣布它已用 Rust 重写了其 Zig 代码库。

Bun 有正当的技术理由。其团队描述了反复出现的内存安全问题，尤其是 JavaScript 的垃圾回收器与 Zig 的手动内存管理之间交互所引发的问题。Rust 的所有权系统提供了对 Bun 的工作负载很有价值的保证。

为此，Bun 还一直在维护自己对 Zig 编译器的修改，而上游贡献的摩擦又加重了维护负担。这本应给 Zig 项目敲响警钟，然而却无人理会。

它最知名的用户之一，拥有雄厚的工程资源，并在这门语言上投入了多年，最终得出结论：继续使用 Zig 不值得。好吧，也合理：并非每个人都必须选择 Zig，也不是每个人都必须永远忠于它。但当一个大用户转身离开时，也许值得问一句为什么，或者在这种情况下，干脆读一读其中的理由。然而，该项目却以一场极其尖刻的公开攻击作为回应。

在对 Bun 重写的一篇长篇回应中，Zig 领导层的表态远远超出了对 Bun 技术论点的不同意。该文批评了 Bun 的工程实践、管理、开发文化和商业决策。它称基金会对于这段关系的结束感到如释重负，并将 Bun 视为一种负担（Zig 项目在为自身任性辩解时似乎特别喜欢用这个词）。而这一切，针对的是一个多年来一直使用 Zig、公开推广它、为其生态做贡献，并向其开发捐赠了大量资金的项目。

Bun 的公告对 Zig 充满赞赏。Zig 的回应则毫无赞赏可言。该文后来经过修订，承认了其早期表述中的怨恨情绪。这算有点诚意，但并不能挽回已经造成的损害——它暴露出项目维护者的不成熟，以及他们对软件开发动态的严重缺乏理解。

一门编程语言并不拥有它的用户。

Bun 没有义务仅仅因为维护者相信 Zig 的设计就继续使用 Zig。它也没有义务按照 Zig 偏好的工程文化来开发软件。如果 Rust 能更好地满足它的需求，那是 Bun 的决定。它甚至不需要为自己辩解，但它这样做了，这展现了对Zig 的风度以及对其自身用户的成熟，而这两种品质正是 Zig 项目严重欠缺的。

而如果 Zig 的维护者不同意 Bun 的技术论证，他们本可以就此展开辩论，而不必把它变成一场关于 Bun 背后的人与文化的公开争端。

这向其他所有人传递了一个尤其令人担忧的信号。如果一个像 Bun 这样知名的项目在离开时都会受到这种对待，那么较小的项目在批评 Zig 或决定离开时又该期待什么呢？这与如何建立人们对一门编程语言的信心相去甚远。事实上，这恰恰会让人不愿依赖它。没有什么比看着一个项目因为其某个用户决定离开就公开大发脾气，更能让人对该项目的治理失去信心的了。

仅凭 Bun 的迁移并不能证明 Zig 是一门糟糕的语言。

但 Zig 处理失去 Bun 的方式，充分说明了该项目的管理水平。

Codeberg 是个糟糕的选择

2025 年 11 月，Zig 宣布从 GitHub 迁移到 Codeberg。

离开 GitHub 本身并不是问题。GitHub 自身有很多问题，而 Zig 对 GitHub Actions 的抱怨也是考虑替代方案的正当理由。问题在于 Zig 去了哪里。

Codeberg 是一家小型非营利 Git 托管服务。根据我的经验，它也令人沮丧地不可靠。我曾多次遇到连接问题，或者在需要它时发现它无法访问。

而且抱怨的远不止我一个人。

当有人建议将 CachyOS 从 GitHub 迁移到 Codeberg 时，CachyOS 论坛讨论中的一位参与者回应道：

“坦率地说，Codeberg 出了名地不稳定，经常出现连接问题。”

其他参与者也提出了大致相同的担忧，其中一位认为 Codeberg 尚未成熟到可以作为 GitHub 的严肃替代品来依赖。

这些仅仅是用户的经验之谈。但它们与我的经历相符，而且可靠性并不是什么只对特别苛刻的用户才重要的冷门特性。它是开发平台的最低要求。

Zig 并不需要留在 GitHub 上。它本可以选择 GitLab，评估其他成熟的托管服务商，或者自建一个 Forgejo 实例。它或许具备这样做的技术能力，但显然更倾向于不去承担那部分工作。自托管当然意味着要付出劳动。但如果掌控自己的基础设施如此重要，或许这正是值得去做的那类工作。

然而，Zig 却将关键的开发基础设施迁移到了一个可靠性存疑的服务商，并试图将其包装为进步。而可靠性方面的担忧甚至还不是最糟糕的部分。

2026 年 7 月，Codeberg 发布了“保护我们的 FLOSS 公共资源免受 LLM 侵害”，解释了其限制某些类别 AI 密集型项目的决定。

Codeberg 完全有权管理其资源、防止滥用，并保护自身免受自动化爬虫的侵扰。但这份公告并未止步于此。它对基于 LLM 的开发本身的正当性做出了笼统的评判。其运营者明确主张，LLM 与负责任的的开源软件开发不相容，而其政策可能会根据代码的生产方式将某些项目排除在外。

对于一个 Git 托管服务商而言，这是一个相当不寻常的方向。正如另一位开发者在“我后悔迁移到 Codeberg”中所说，令人担忧的不仅是当前哪些项目受到限制，而是该托管服务商自行决定哪些原本正当的软件开发形式属于其平台。

你不必喜欢 AI 也能看出这里的问题。Codeberg 自称是自由及开源软件的家园，却似乎越来越热衷于决定哪些类型的软件开发值得被欢迎。显然，公共资源只有在所有人都认同其使用方式时才是公共的。

一个 Git 托管平台应当托管代码、管理议题并促进协作。它应当执行合理的限制并防止滥用。它不应需要对一个项目的开发理念是否足够高尚做出评判。

Codeberg 的公告是在 Zig 迁移之后发布的，因此它并不能确定维护者在当时知道些什么。但事后看来，这无疑让他们的选择显得更加糟糕。

Zig 用 GitHub 的问题换来了另一组问题：据我的经验，可靠性更差，而且托管服务商越来越热衷于监管软件应当如何编写。

而且，由于该项目自身的政策与那种理念相一致，我很难相信实际考量是做出这一选择的唯一原因。

显然，连捐赠都可能是错误的那种

GitHub 迁移公告中还包含一段关于 GitHub Sponsors 的特别奇怪的文字。

在承认该平台对 Zig 的筹款有多么重要之后，维护者们写道：

“尽管 GitHub Sponsors 占 Zig 软件基金会捐赠收入的很大一部分，但我们认为它是一项负债。”

随后他们请求支持者将定期捐赠转移到 Every.org，并宣布取消 GitHub Sponsors 的福利。我必须再次发问，为什么？

Zig 在很大程度上依靠捐赠获得资金。人们自愿向该项目捐款，以便其开发者能够继续开发这门语言。而现在，人们一直用来支持它的平台之一竟然成了负债？昨天还是资产，今天就成了负债？

诚然，依赖第三方平台存在风险。GitHub Sponsors 明天就可能更改条款。但这是分散筹款渠道的理由，而不是抛弃现有渠道的理由。为什么不把仓库作为只读镜像留在 GitHub 上，并继续在那里接受捐赠呢？

为什么那些已经在支持 Zig 的人，仅仅因为维护者不再喜欢 GitHub，就必须改变他们的支付方式？实际开发完全可以全部在 Codeberg 上进行。没有人必须使用 GitHub 来处理 issue、pull request 或 CI。而那些偏好 GitHub Sponsors 的人可以继续通过它捐款。

也许有行政上的原因想要把筹款集中到别处。但公告并没有说明为什么保留两个渠道是不可接受的。维护者确实感谢了现有的支持者，他们也没有字面意义上地拒绝捐款。但我仍然觉得这条消息极其缺乏敏感度。

当你的项目依赖自愿贡献时，让人们支持你变得更不方便，这需要比“不喜欢他们碰巧使用的平台”更好的解释。

拒绝依赖 GitHub 进行开发是一回事。把这种偏好变成对那些想给你钱的人的不必要摩擦，则是另一回事。

又一次，其他所有人都被期望去迁就 Zig 的原则。

无路可走

Zig 没有死。开发仍在继续，编译器也在不断变好。

但技术进步并不等同于成熟。如果使用一门日益精密的编程语言仍然是一场紧跟破坏性变更和项目管理任性的练习，那它再好又有什么用？

看看这个模式。用户被期望跟上不稳定的语言。贡献者被期望按批准的方式工作。一个重要的下游用户决定 Rust 更合适，项目就公开抨击。托管平台变了，捐赠者被要求跟着迁移。

Zig 的维护者期望其他所有人适应这个项目，却表现出惊人的不愿让项目适应其他人。

毫无疑问，他们有权按自己的方式运营 Zig。开源并不意味着维护者欠每个人无限的支持、免费的代码审查或永久的向后兼容。但反过来同样成立：用户不欠维护者他们的时间、忠诚或对其理念的认同。

开发者想写软件，而不是花无数小时迁移标准库 API。贡献者可能想修个 bug，而不是证明对某个受认可工程学派的忠诚。公司想要一门能解决其问题的语言，而不是关于如何经营业务的说教。捐赠者想支持一个项目，而不是卷入它与 GitHub 的纠纷。

好的项目管理意味着做出妥协。有时这意味着把稳定性置于又一次优雅的重设计之上。有时这意味着接受一个不认同你偏好的开发意识形态的人提交的有用补丁。有时这意味着当一个主要用户离开时咽下骄傲。有时这意味着选择无聊、可靠的基础设施，而不是发表哲学声明。

Zig 似乎决心做任何事，唯独不做这些。

这一切并非不可避免。Zig 可以在保持技术雄心的同时，成为一种可靠得多的语言，以及一个容易合作得多的项目。但这需要其维护者开始把用户的需求当作比需要应付的麻烦更重要的事情来对待。

这个项目可以永远不断完善其语言设计。它可以继续坚持自己对优秀工程的理念，拒绝错误类型的贡献，并选择符合其世界观平台。

但在某个时刻，它需要决定：它想要构建的是一门人们可以使用的编程语言，还是一个关于其维护者认为软件应如何开发的持续实验。

Zig 花了十多年时间弄清楚其维护者希望这门语言成为什么样子。也许现在是时候让他们开始多关心一点用户需要它成为什么样子了。

在那之前，Zig 项目将毫无进展。

作为对比，Go 1.0 于 2012 年 3 月发布，距离其 2009 年公开亮相约两年半；Rust 1.0 于 2015 年 5 月推出，距离其早期公开开发约五年。你怎么理解都行。
↩