Zig / 博客文章

重返 Zig（Returning to Zig）

约 4 小时前发布

文章概要

标题：重返 Zig（Returning to Zig）
作者：Anna
发布日期：2026年6月10日
阅读时间：9分钟
原文链接：https://gracefulliberty.com/articles/return-to-zig/

本文作者回顾了自己从 Zig 转向 Rust，如今又重返 Zig 的经历。文章详细阐述了 Zig 语言的吸引力、Rust 的优缺点，以及促使作者回归 Zig 的原因，并评价了 2026 年 Zig 的现状。

详细总结

1. 最初为何热爱 Zig

  • 2020 年经导师介绍接触 Zig，当时正在学习 C 语言，对 C 落后的抽象和糟糕的工具链感到沮丧。
  • Zig 被宣传为 C 的替代品，具有编译期代码执行和简洁的抽象能力。
  • 受 Andrew Kelley 演讲《软件应当完美》影响，认同其强调的显式内存分配、无隐藏控制流和通用可复用性等价值观。

2. 为何离开 Zig 转向 Rust

  • 语言不稳定：Zig 频繁破坏代码，学生时代没时间应付版本更新（当时还没有 anyzig 这类多版本管理工具）。
  • 生态不成熟：库少、示例少、标准库经常变动，文档也不稳定。
  • Rust 的优势：稳定、生态强大，学习曲线虽陡但学会后能高效工作，帮助建立了内存模型认知。

3. 为何重返 Zig

  • Rust 的不完美之处：FFI 困难、交叉编译繁琐、隐藏的不可失败内存分配、受限于 LLVM 导致平台支持有限。
  • 治理问题：Rust 项目有大型企业基金会成员，可能影响发展方向。
  • 导火索：面对 AI 生成代码（vibecoding）泛滥，Zig 项目全面禁止 LLM 生成代码，而 Rust 项目最初的回应政策中禁止讨论 LLM 的长期影响、版权等话题，引发作者信任危机。

4. 2026 年的 Zig 现状

  • 仍不稳定：0.17.0 即将发布，会破坏构建系统；最佳实践是保留一份标准库源码随时查阅。
  • 核心语法变化不大：2020 年的知识仍然适用，标准库部分重写但代码易读。
  • 新增包管理器：支持 git 和压缩包依赖，内置工具大幅改进。
  • 生态依然不大，但这是有意为之——没有官方包 registry，避免重蹈 NPM 或 crates.io 覆辙。

5. 关于内存安全性的讨论

  • Zig 未提供 Rust 那样的编译期内存安全保证，这是为了保持简单性而做的权衡。
  • Zig 的 ReleaseSafe 模式会在运行时进行断言检查和内存初始化，未来可能引入类似 Fil-C 的机制。
  • 作者认为内存安全是一个光谱，Zig 通过测试和模糊测试来保证正确性，在证明正确后可以用其他发布模式构建。
  • 如果 Rust 的类型系统和编译时间成本对你来说值得，那就用 Rust；但并非所有场景都如此。

6. 结论

  • 作者准备好用 Zig 应对各类软件问题，低级细节用 Zig，脚本任务用其他语言。
  • 不排除未来会因稳定性或类型系统需要回到 Rust，但 Zig 所代表的追求完美、关注软件质量的愿景与作者高度共鸣。
  • 在 LLM 时代，精心打造的软件变得稀缺，而 Zig 坚持提供可靠、强大的软件，这尤为重要。

全文中文翻译

重返 Zig

从 Zig 到 Rust，再回到 Zig

2026-06-10 · 9 分钟 · #编程

Zig 正在崛起。虽然它还未占据 Rust 或 Go 已有的空间，更不用说 C 了，但它已被几个大型项目和无数小型项目采用。因此，它正在成为一门面向未来的重要语言。我对 Zig 感兴趣已有数年，于是决定重新审视这门语言，看看如今我对它的感受如何。

我为何曾热爱 Zig

我第一次接触 Zig 是在 2020 年，由一位编程导师介绍。他们对这个拥有编译期代码执行和优美简洁抽象能力的新语言充满热情。我也决定去了解一下。

那时我还在深入学习 C。我喜欢对计算机的强大掌控力，但对陈旧的抽象和糟糕的工具链感到沮丧。Zig 虽然新颖且不稳定，但被承诺为 C 的替代品。这吸引了我。既然能学下一代语言，为什么还要学 C 呢？

我观看了更多 Andrew Kelley 的演讲。《软件应当完美》对我影响深远，它塑造了我对编程语言——以及整个软件——应有的样貌的看法。在那次演讲中，Andrew 强调了可失败、显式的内存分配、无隐藏控制流和通用可复用性的重要性。这些价值观都成为我在任何编程语言中寻求的目标。

于是我转向了 Zig。我编写了玩具编程语言、尝试了文学编程工具、玩了玩 Web 服务器。我很享受用 Zig 工作。它比 C 更友好，且没有那么多陷阱。

离开去 Rust

Zig 不断破坏我的代码。我厌倦了这种变动。我当时是个学生，没有太多时间让代码跟上最新版本的语言。那时还没有 anyzig 让在同一系统上管理多个 Zig 版本变得轻松。我常常相隔数月才重新处理某个项目，回来后就得进行我不理解的大规模重构才能让它们再次工作。

Zig 的生态也不成熟。作为一名新程序员，我没有能力独立实现所有功能。库极少，示例也少。标准库不断变化，每次我以为理解了其抽象的工作方式，它们就又变了。默认文档不稳定也无济于事。

所以我离开了，去了 Rust。那时 Rust 已经稳定多年，拥有强大的生态。学习它很痛苦——我好几次想放弃——但一旦学会，它就能稳定工作。这对我而言非常宝贵。一门快速、底层、具有表达力且没有不稳定代价的编程语言。它还迫使我建立了内存模型思维，这对那些内置检查较少的语言也大有裨益。

额外的好处是，只要代码不 panic，我就能写出没有隐藏控制流或垃圾回收的可复用代码。虽然它隐藏了内存分配，且与 C 的交互困难，但它几乎让我回到了当初 Zig 吸引我的原点。

我爱 Rust。至今我仍喜欢用它工作。它的抽象带给我快乐。不幸的是，我对项目发展的一些方向感到担忧。

我为何回归

Rust 仍不完美。虽然它提供了我在编程语言中寻求的许多东西，但它并非最适合制作我想要的可复用程序。FFI 很困难，交叉编译令人烦恼，隐藏的不可失败内存分配困扰着我。由于绑定在 LLVM 上，它要支持像 C 一样多的平台还需要很长时间（如果真能实现的话）。

此外，它的治理也一直让我不安。它有几个大型企业基金会成员，几乎肯定会影响 Rust 的开发方向。当世界上最大的公司每年给你数十万美元时，你可能不想让他们不高兴。

抛开这些不谈，我本可以接受，直到“氛围编程”（vibecoding）的祸害冲击了开源社区。令我恐惧的是，许多软件项目都在接受 LLM 生成的代码。我原以为 LLM 在开发者中不受欢迎，我以为唯一使用它们的人是受雇主所迫。

当这种情况发生时，维护者和用户都撰写或要求制定 LLM 政策。Zig 完全禁止了它们。与此同时，Rust 却慢慢来。他们做了些调查，社区普遍情绪是反对 LLM 的，但他们尚未准备好制定官方政策。

当他们最终提出一个提案时，其中包含了臭名昭著的调解政策：

“对本 PR 的评论不得提及以下主题：

  • LLM 的长期社会或经济影响
  • LLM 的环境影响
  • 任何与 LLM 输出版权状态相关的内容
  • 对使用 LLM 的人进行道德判断”

该内容在遭到反对后被移除，但这一事实已经让我对未来 Rust 项目的信任受损。我爱这门语言，但对其治理感到沮丧。

该政策本身没问题。它几乎完全限制了 LLM，减少了大量垃圾内容。它不像 Zig 的政策那么严格，但可行。但这整个经历让我几年来第一次认真地重新探索 Zig。

2026 年的 Zig

我注意到的第一件事是语言仍然不稳定。当我尝试使用网上找到的 0.16.0 示例时，发现它们已经过时了。我明白在 Zig 中提高生产力的最佳方式是保留一份标准库源码并熟悉它。

我对 Zig 的稳定性不抱幻想。Zig 0.17.0 即将发布，它将破坏每个项目的构建系统。我理解维护者打算转向稳定化，而这些破坏是这一过程的一部分。

幸运的是，语言本身自 2020 年以来变化不大。我发现我的大部分直觉仍然适用。库中有一些东西被重写了，但代码易于阅读，我很快就找到了方向。我相信今天的 Zig 代码在六年后仍然会很容易辨认。

我还注意到 Zig 现在有了包管理器。我记得我离开时它还在开发中。我记得当时用 git submodule 管理依赖。内置工具好多了。项目可以通过 git 和压缩包定义依赖。vendoring 毫不费力。一切都很好用。

生态系统仍然不广泛，但这从来不是 Zig 的目标。没有官方包 registry 是有原因的。我们不需要另一个 NPM 或 crates.io。对我来说，Zig 达到了完美的平衡。

但内存不安全！

我知道 Zig 不提供 Rust 那样的内存安全保证。不幸的是，这是他们为了简单性而做的权衡。Rust 仿射类型的复杂性不值安全性的好处。

这并不是说他们放弃了安全。Zig 比 unsafe Rust 更安全。所以当你发现自己不得不写 unsafe Rust 时，Zig 可能是更好的选择。

Zig 也在努力让语言更安全。他们的方法侧重于发布模式，而不是 unsafe 代码段。目前，Zig 的 ReleaseSafe 模式会在断言失败时崩溃，并初始化所有内存。但 Andrew Kelley 有兴趣进一步推进，在 ReleaseSafe 中引入类似 Fil-C 的东西。虽然这不能提供 Rust 那样的编译期内存安全（假设你避免使用 unsafe），但这也不会像有些人说的那样是死亡螺旋。

内存安全是一个光谱。没有一种内存安全方法能在所有情况下都表现最佳。Zig 的方法是让 ReleaseSafe 在运行时尽可能安全，然后通过测试和模糊测试来确保正确性。任何未检查的非法行为都应该在此过程中被发现。在正确性得到证明后，二进制文件应该可以在另一种发布模式下安全发布。

与 Rust 模型相比，这种方法有一些缺点，但它并非严格劣于 Rust，尤其是当 Zig 追求 Rust 难以企及的简单性时。有许多编程语言，你可以选择最适合你用例的那一种。如果编译期内存安全值得复杂类型系统和长编译时间的代价，那就去用吧。但这并不适用于每个人的每种情况。

Zig 的内存安全模型延伸到了其断言哲学。Zig 不会在 ReleaseFast 中禁用断言，而是信任你已经完成了所需的测试，证明你的断言是正确的且那些路径不可达，从而允许 Zig 优化代码。

Zig 要求完美，但它也提供了达到完美的工具。

结论

因此，手持标准库和发布更新日志，我已准备好用 Zig 应对任何软件问题。当我不想处理底层细节时，我会用我的脚本语言，但 Zig 将是我未来软件的主力。

我有可能不会一直用 Zig。我可能会在需要稳定性或其类型系统时求助于 Rust。也有可能我完全改变对 Zig 方法的看法。多种语言可以而且应该共存。

但 Zig 代表了一种与我产生共鸣的软件愿景。一种关注用户、不是通过忽视软件质量、而是通过拥抱它的方式。人们值得拥有可靠、强大的软件。这在 LLM 时代尤其如此，精心打造的软件变得稀有，人们被迫接受不断恶化的“垃圾”。

加入开源交流群

请加站长微信，免费进入交流群，和开源爱好者一起讨论。

站长微信二维码