Zig 编程语言因管理问题和持续的不稳定性面临批评

尽管经过了十年的开发，Zig 编程语言仍处于永久的 0.x 状态，经常破坏与其自身标准库和构建工具的兼容性。这种持续的不稳定性导致了项目维护者（他们优先考虑特定的软件开发愿景）与依赖该语言进行生产软件开发的开发者之间日益扩大的分歧。

这张图片作为该项目在迈向稳定 1.0 版本方面缺乏进展的视觉总结。

持续不稳定性带来的负担

Zig 的开发周期以其 I/O 接口和标准库的频繁、重大变更为特征。例如，0.15.1 和 0.17.0 版本引入了重大变化，通常要求开发者重写现有代码的大部分并更新依赖关系。

由于该语言属于基础设施，这些不断的变更造成了巨大的维护负担。开发者往往被迫在冻结项目在旧版本编译器上，或投入持续的工程精力来跟上上游变更之间做出选择。

“在什么时候，维护你的 Zig 代码会开始变成软件开发，而不是变成由 Zig 项目布置的家庭作业？”

— The Zig project is going nowhere

限制性的贡献和 AI 政策

Zig 项目对 AI 生成的代码保持极其严格的政策，禁止 AI 辅助编辑、翻译甚至寻找 Bug。维护者辩称这是为了确保贡献者能够深入理解语言的内部机制。

批评者认为这一政策优先考虑开发的“过程”而非贡献的“价值”。通过仅仅因为 LLM 帮助生成代码就拒绝有用的代码，该项目被指责在强加教条而非技术严谨性。

用户摩擦与基础设施变迁

该项目的管理风格在其对高性能 JavaScript 运行时 Bun 的公开回应中得到了体现。在 Bun 宣布使用 Rust 重写后，Zig 领导层对 Bun 的管理和文化发表了尖锐的公开批评。

此外，Zig 从 GitHub 迁移到 Codeberg 引起了对可靠性的担忧。虽然此次迁移旨在避开 GitHub 的基础设施，但 Codeberg 是一个较小的非营利服务，一些社区成员报告称其经常出现连接问题和不稳定。

项目愿景的权衡

核心矛盾在于编程语言应该是实用的工具，还是特定工程哲学的平台。虽然维护者辩称他们的选择保护了语言的完整性，但批评者认为这些决定使得其他人在上面构建可靠软件变得越来越困难。

随着项目在雄心勃勃的技术目标与用户群的实际需求之间寻求平衡，其未来仍不确定。它能否在保持当前管理风格的同时实现稳定的 1.0 版本，仍然是争论的焦点。