Zig为何尚未发布1.0版本

大多数编程语言都遵循一条熟悉的轨迹：早期的实验性版本、快速迭代，然后在某个时间点发布1.0版本，标志着稳定性和正式应用的潜力。

Zig 并未遵循这条常规路径。原因何在？

2018 年，Andrew Kelley 辞去工作，全身心投入一门编程语言的开发。八年后，Zig 支撑起了 Ghostty、TigerBeetle 以及 Uber 的交叉编译能力。它在 Stack Overflow 上位列最受推崇的语言前五名。但唯独缺少一件事——1.0 版本的发布。对许多工程师来说，这引出了一个显而易见的问题：“为什么花了这么久？” 更重要的是：“这值得担忧吗？”

在最近与 JetBrains 的一次对话中，Zig 的创建者 Andrew Kelley 相当直接地回应了这些问题。答案或许会令你惊讶！

🎥 观看完整访谈 → https://jb.gg/andrew-kelley-zig-interview

一个熟悉的里程碑，却有着不熟悉的定义

在大多数生态系统中，1.0 版本清晰地传递出稳定性、成熟度以及向后兼容的承诺。这是许多团队在将一项技术投入生产环境前等待的信号。

但正如 Kelley 指出的，这个定义并不像表面看起来那样清晰。1.0 版本的核心，不过是一个承诺——保证未来的更改不会破坏现有代码。除此之外，它对于一门语言是否真的做好了长期使用的准备，所能说明的内容少得惊人。

不同语言对这个里程碑的理解大相径庭。有些语言早早锁定了功能，之后避免重大改动。另一些则发布了 1.0 版本，却在底层持续快速演进。版本号保持不变，但语言本身却在不断变化。

Zig 选择了一条完全不同的道路。

有意不发布

Kelley 的观点中引人注目的是：Zig 迟迟没有 1.0 版本并非疏忽或延误——而是有意为之。

项目并没有急于宣告稳定，而是优化了另一件事：在锁定基础之前，先把基础做对。

了解 Zig 是如何构建和维护的，这个决定就更容易理解了。与许多现代语言生态系统不同，Zig 没有风险投资支持，也不受企业时间表驱动。它由一个独立的、小型团队在非营利基金会下开发，主要依靠个人捐助。

这种结构消除了开发者面临的一种常见压力。

没有增长目标需要达成，不需要为了面子而发布里程碑版本，也没有外部力量推动项目走向一个仓促定义的“完成”。结果是，开发过程可以有耐心，甚至在某些情况下刻意放慢脚步。

但这种耐心自然会带来权衡。

[LOADING...]

等待的代价

毫无疑问，1.0 版本的发布会加速 Zig 的采用。许多公司和开发者将此标签作为准入信号或信任的代名词。

Kelley 公开承认这一点。当 Zig 最终达到 1.0 时，采用率很可能会跃升。

然而，项目仍然优先考虑长期设计而非短期增长。

这种张力——采用率与细节关注之间的张力——正是 Zig 的方法变得特别有趣的地方。项目没有问“我们多快能达到 1.0？”，而是提出了一个不同的问题：

“如果我们今天发布了，将来会后悔锁定了什么？”

这个反传统但令人耳目一新的框架，将目标从速度转向了永久性。

关于进展的不同哲学

放大来看，这种方法不仅仅关乎版本号——它反映了贯穿 Zig 设计的一种更广泛的哲学。

当某些生态系统信奉“快速发布，之后修复”的心态时，Zig 试图寻找一种中间地带，使其能够以最小的复杂性提供强大的能力，而不会积累长期的设计债务。

Kelley 将这种方法描述为旨在“以少胜多”，这转化为在简单性中寻找杠杆作用，而不是堆砌功能或抽象。

这种哲学超越了语言本身。它塑造了关于工具、依赖甚至社区流程的决策。核心主题是一致性：现在避免不必要的复杂性，这样你就不必永远支持它。

从这个角度看，Zig 迟迟没有达到 1.0 并非犹豫——而是克制。

重新思考“准备好”意味着什么

这一切引出了一个更广泛的问题，超越了 Zig：一项技术“准备好”究竟意味着什么？

如果 1.0 只是一个兼容性承诺，那么依赖它作为信号是否合适？或者它已经成为了更微妙的东西（如信任、生态成熟度或长期稳定性）的替代指标？

Zig 的方法挑战了这个问题的一个基本前提。它暗示，准备就绪可能不是一个单一的里程碑，而是一系列关于不要过早敲定什么内容的深思熟虑的决策。

这种方法最终是加速还是限制了采用，还有待观察。

[LOADING...]

观看完整对话

以上虽然有趣，但只是更广泛讨论中的一条线索。在完整访谈中，Andrew Kelley 深入探讨了从 Zig 相对于 C 和 Rust 的定位，到对 AI 生成贡献的态度，再到未来十年编程可能的面貌等话题。

如果你对系统编程——以及更广泛的语言设计——的发展方向感兴趣，那么这次访谈值得一看。