因不信任Rust治理，开发者回归Zig

背景

一位曾深深着迷于 Zig 语言、因稳定性问题转向 Rust 的开发者，在 2026 年重新审视 Zig 社区后宣布回归。他的回归并非因为 Rust 技术上的缺陷，而是出于对 Rust 项目治理方向——尤其是对待 LLM 生成代码的态度——失去了信任。

核心内容

2019 2020 年左右，作者在一位编程导师的推荐下第一次接触 Zig。当时他正深入 C 语言的学习，享受对计算机底层控制的同时，也厌倦了 C 的过时抽象和糟糕的工具链。Zig 承诺作为 C 的替代品，拥有编译期代码执行和简洁的抽象形式，这让他立刻被吸引。他观看了 Andrew Kelley 的演讲《Software Should Be Perfect》，其中强调的“可失败的显示内存分配”“无隐藏控制流”和“通用可复用性”成为他衡量编程语言的标准。

于是作者转向 Zig，写了一些玩具编译器、文字编程工具和 Web 服务器。然而 Zig 频繁的破坏性更新让他筋疲力尽——当时的 Zig 还没有 zig 工具来管理多版本，他经常需要在隔了几个月后重新回来进行不理解的大型重构。Zig 生态的不成熟也令新手难以独自实现所有功能：库很少、文档不稳定、标准库抽象不断变化。

无奈之下他转向 Rust。那时 Rust 已经稳定多年，生态强大。虽然学习过程痛苦，但一旦掌握，其稳定性和表达能力正是他需要的——快速、底层、无隐藏控制流、无垃圾回收，还强迫他建立了内存模型。Rust 隐藏内存分配且与 C 的 FFI 困难，这让他几乎回到了对 Zig 的渴望上。

但他始终对 Rust 的治理感到不安：几个大企业基金会成员每年提供数十万美元，很可能影响语言发展方向。更致命的是，当“vibecoding”风气（大量使用 LLM 生成代码）冲击开源社区时，Zig 项目直接禁止了 LLM 生成代码，而 Rust 项目在长时间讨论后提出的政策中包含了臭名昭著的“不得讨论 LLM 的长期社会/经济影响、环境影响、输出版权、对使用者的道德评判”等限制。虽然该条款后来因反弹被删除，但此事让作者彻底失去了对 Rust 项目未来治理的信任。

2026 年，作者重新认真审视 Zig。语言仍然不稳定（0.17.0 即将发布，会破坏所有项目的构建系统），但他发现核心概念变化不大，代码易读，自己的直觉仍然适用。好消息是 Zig 现在有了包管理器，依赖管理通过 git 和 tarball 完成，vendor 开箱即用。生态依然不庞大，但这是有意的——Zig 不想变成另一个 NPM 或 crates.io。

关于内存安全，作者意识到 Zig 不提供 Rust 那样的编译期保证，但这是一种权衡：复杂仿射类型带来的安全收益不值得牺牲简洁性。Zig 比 unsafe Rust 更安全。Zig 的 ReleaseSafe 模式会在断言失败时崩溃并初始化所有内存，Andrew Kelley 还计划进一步用类似 Fil-C 的方案增强运行时安全。内存安全是一个光谱，Zig 的策略是让 ReleaseSafe 尽可能安全，然后通过测试和 fuzzing 确保正确性。

关键要点

• Zig 早期痛点：频繁破坏性更新、生态不成熟、标准库/文档动荡，迫使作者转向 Rust。
• Rust 的优势：稳定、生态强、表达力好、强制建立内存模型，但隐藏内存分配、FFI 困难、绑定 LLVM 限制平台支持。
• Rust 治理问题：大企业赞助影响方向；对 LLM 代码政策初期包含限制讨论的条款（虽撤销），导致信任崩塌。
• 2026 年 Zig 现状：仍不稳定但核心未变；包管理器成熟；生态小巧但有意为之；内存安全策略走运行时安全 + 测试路线。
• 内存安全观点：不存在万能方案；Zig 的 ReleaseSafe 模式配合测试/fuzzing 可在实用性与安全性间取得平衡。

意义与影响

这篇经历折射出开发者选择编程语言时，技术特性往往不是唯一决定因素。社区治理、开源项目对新兴技术（如 LLM 生成代码）的态度正在成为新的分水岭。Zig 果断禁止 LLM 代码的姿态吸引了那些注重人工审计和项目纯洁性的开发者；而 Rust 因大企业影响和慢速决策，即使技术优越也可能流失核心用户。

文章还提醒我们，“稳定性”是相对的：Zig 虽然在语法上仍不稳定，但其设计哲学和运行时安全策略的演进方向更加透明且聚焦。对于一个有意不追求主流生态、专注 C 替代的语言来说，找到一批志同道合、信任其治理的用户比争夺市场份额更重要。

最后，内存安全并非非黑即白。Zig 采用运行时检测 + 测试的组合，Rust 采用编译期静态分析，两者各有适用场景。这场个人回归背后，是开发者对语言治理透明度和价值观一致性的强烈需求。