Zig发展轶事(202x)
2024-10-09 14:08:11 
阿炯
本文主要用于记录Zig编程语言发展和使用过程中的大事记，截止到2030年前。HashiCorp 创始人向 Zig 软件基金会捐赠 30 万美元
宣布从 GitHub 迁移至 Codeberg
全面禁止 LLM 辅助贡献：押注于人而非代码
Mitchell Hashimoto 向 Zig 软件基金会捐赠 30 万美元
Zig 软件基金会 (ZSF) 于2024年10月上旬宣布获得了来自 HashiCorp 联合创始人兼首席执行官 Mitchell Hashimoto 与其妻子的 30 万美元承诺捐款，以个人名义捐赠。捐款将分成两笔 15 万美元的付款，第一笔款项已经完成转账，另一笔计划一年后支付。ZSF 在公告中明确阐述了他们的使命以及这笔钱的具体用途：
在过去的几年中，Zig 项目的采用率和贡献者数量都得到了显着增长，以至于开发活动的数量已经超过了我们获得的捐款数量。我们目前有越来越多的 PR 需要审查，并且有一批有资格完成这项工作的核心贡献者，但没有足够的资金来支付计费时间，无法完全满足需求。就在上周，为了控制日益增长的云基础设施成本，我们放弃了 AWS，甚至在此之前，我们 90% 以上的收入一直用于支付贡献者的时间。这不是理所当然的事情，因为非营利组织很容易产生不成比例的运营开销。
因此，ZSF 计划使用这笔资金继续为核心捐助者提供就业机会：譬如为 Jacob Young 提供全职工作，“他是 C 语言后端、x86 后端、增加了 Zig 支持的 LLDB fork 的主要作者，同时还负责维护 eZ80 工具链。”
除了对 Mitchell 表达感谢外，ZSF 还感谢了 Bun 和 TigerBeetle 对 ZSF 和 ZigTools（支持 ZLS 开发的社区计划）的财政支持，以及在今年早些时候成为 ZSF 的赞助商的 ZML。Mitchell 也在个人博客中阐述了自己支持 ZSF 的原因，并呼吁更多人为 ZFS 进行捐赠：
我从 2019 年的某个时候就开始关注 Zig 项目。我在 2021 年公开分享了我对该项目的兴奋之情。那年晚些时候我开始使用 Zig，到 2022 年初，我开始 撰写有关 Zig 的文章并 为编译器做贡献，从那时起，我继续做了几十个代码贡献。2023 年我公开分享了我的终端项目 Ghostty，它是用 Zig 编写的。现如今我大部分的编码时间都花在了 Zig 上。
我的家人喜欢支持我们所信仰的事业。作为其中的一部分，我们希望支持那些我们认为可以带来变革和影响的独立软件项目，这既是回馈给予我如此之多的社区的一种方式，更重要的是，这也是彰显和鼓励为热爱而建设的文化的一种方式。Zig 就是其中一个项目。
Zig 从一开始就是一个充满激情的项目，并且一直如此。它管理良好，社区强大，融资模式透明且可持续。作为一项技术，它雄心勃勃且富有创新性，但仍然实用且务实。它要达到稳定和更广泛的行业采用还有很长的路要走，但我相信它有一条清晰的道路和机会来实现这一目标。
明显 Bug 拖三年不修，Zig 宣布从 GitHub 迁移至 Codeberg
因对 GitHub 持续恶化的服务质量失望，Zig 软件基金会于2025年12月宣布将项目迁移至非营利代码托管服务 Codeberg。据悉事件起源于一个名为 "safe_sleep.sh 脚本无限期挂起" 的 bug。2022 年 2 月，GitHub 将 posix "sleep" 命令替换为 "safe_sleep" 脚本，但该脚本存在明显缺陷 —— 如果进程未在 1 秒间隔内被调度运行，脚本就会陷入死循环，持续占用 100% CPU。
Zig 核心开发者 Matthew Lugg 在 2025 年 4 月的错误报告中指出：" 在负载极高的 CI 服务器上，这种情况很容易发生。一旦发生，后果非常严重：它会彻底摧毁一个运行器，直到人工干预。在 Zig 的 CI 运行器服务器上，我们观察到多个这样的进程已经运行了数百小时，悄无声息地导致两个运行器服务器宕机数周。"
尽管该问题在 2025 年 4 月被正式报告，GitHub 直到 8 月 20 日才合并修复代码，且从未在原讨论帖中回应，该帖直到 12 月 1 日才被关闭。更讽刺的是，修复方案早在 2024 年 2 月就已提出，但在一年多时间里未经审查，还曾在 2025 年 3 月被 GitHub 机器人自动关闭。
Zig 软件基金会主席兼首席开发者 Andrew Kelly 在宣布迁移时称："GitHub Actions 存在不可原谅的漏洞，却完全被忽视。GitHub 的 CEO 曾说过 ' 要么拥抱 AI，要么滚蛋 '，看来微软的那些走狗们领会了其中的含义，因为 GitHub Actions 开始 ' 随机调度 '—— 看似随机地选择要运行的任务。再加上其他漏洞以及无法手动干预，这导致我们的持续集成系统严重积压，甚至连主分支的提交都无法检查。"
Kelly 随后为这篇 "煽动性帖子" 道歉，但 Zig 基金会的迁移决定并未改变。
Answer.AI 和 Fast.AI 联合创始人 Jeremy Howard 在社交媒体上表示："这个漏洞的实现方式非常明显，几乎任何人一眼就能看出它会一直占用 100% CPU，并且除非任务恰好在正确的时间检查时间，否则它会一直运行下去。我实在无法理解，这样一系列令人瞠目结舌、匪夷所思的事件是如何在一个正常运转的组织中产生的。"
Zig 并非唯一离开 GitHub 的项目。Dillo 浏览器项目创建者 Rodrigo Arias Mallo 上周末也宣布计划离开 GitHub，理由包括过度依赖 JavaScript、可用性下降、审核工具不足，以及 "过度关注 LLM 和生成式 AI，这些正在摧毁开放网络"。
自2025年1月以来，非营利代码托管平台 Codeberg 的支持会员人数已从 600 多人翻倍至上周的 1200 多人。相比之下，GitHub 尚未透露当前付费用户总数。微软 CEO 萨蒂亚・纳德拉在 2025 年第三季度财报会上称 "GitHub Copilot 用户超过 1500 万，同比增长超过 4 倍"，但未说明有多少用户为 Copilot 或其他服务付费。2024 年第四季度，GitHub 年收入运行率为 20 亿美元，其中 GitHub Copilot 订阅收入约占年增长的 40%。
全面禁止 LLM 辅助贡献：押注于人而非代码
2026年4月下旬，知名开发者 Simon Willison 在其博客发文，详细解读了 Zig 编程语言项目近期出台的严格反 AI 贡献政策（可查看Zig 项目官方政策）。这项政策明确禁止在所有 issue、Pull Request 及评论中使用 LLM 辅助生成内容，引发了开源社区对 "AI 与开源治理" 关系的广泛讨论。
Zig 项目核心维护者的立场非常鲜明：开源项目的终极目标不是获取代码，而是培养长期可信的贡献者。用他们自己的话说，"you play the person, not the cards"（你押注的是人，而非手中的牌）。审查 Pull Request 的首要目的从来不是合并代码本身，而是帮助新贡献者成长，让他们理解项目规范、建立信任关系。一旦引入 LLM 辅助，这个培养过程就被架空了 —— 维护者无法判断提交者是否真正理解自己的代码。
试问如果一个 PR 主要由 LLM 编写，那么项目维护者为什么要花时间审查和讨论这个 PR，而不是启动自己的 LLM 来解决同样的问题呢？
这一观点得到了颇具说服力的现实佐证。Bun（基于 Zig 构建的高性能 JavaScript 运行时）已被 Anthropic 收购，团队内部重度使用 AI 辅助开发。然而即便如此，Bun 团队仍然无法向 Zig 上游提交 AI 辅助生成的优化代码，因为其根本不符合 Zig 项目对 "真实人类贡献者" 的要求。
Zig 项目的逻辑并非排斥技术进步，而是对开源社区长期健康的审慎考量。当 AI 可以瞬间生成看似合格的代码时，项目维护者面临的最大风险不再是代码质量，而是无法识别 "谁在真正学习、谁只是让 AI 代笔"。这种信息不对称会瓦解 mentorship（导师制）这一开源社区最核心的传承机制。