重返Zig

# 回归 Zig 来源：https://gracefulliberty.com/articles/return-to-zig/ 从 Zig 到 Rust 再到 Zig 2026-06-10 · 9 分钟 · #计算 (https://gracefulliberty.com/articles/tags/computing) Zig 正在逐渐流行。它尚未占据像 Rust 甚至 Go 那样的地位，更不用说 C 了，但它已被一些主要项目和无数较小的项目采用。因此，它正在成为未来一种重要的语言。由于我对 Zig 感兴趣已有几年，我决定重新审视这门语言，看看今天我对它的感受如何。 ## 为何我热爱 Zig 我在 2020 年通过一位编程导师第一次接触到 Zig。他们对这个具有编译时代码执行能力和优雅而简单的抽象形式的小新语言充满热情。我决定也去了解一下。 当时，我还在深入学习 C 语言。我享受对计算机的控制权，但对过时的抽象和糟糕的工具感到沮丧。Zig 虽然新且不稳定，但被承诺为 C 的*替代品*。这吸引了我。既然我能学下一代语言，为什么还要学 C 呢？ 我看了更多 Andrew Kelley 的演讲。《软件应当是完美的》(https://www.youtube.com/watch?v=Z4oYSByyRak) 对我影响深远。它塑造了我对编程语言——以及软件整体——应该是什么样子的看法。在那次演讲中，Andrew 强调了可失败的显式内存分配、无隐藏控制流以及通用可重用性的重要性。这些价值观成为了我在任何编程语言中寻找的品质。 于是我转向了 Zig。我写了玩具编程语言，尝试了文字编程工具，并摆弄了 Web 服务器。我喜欢使用 Zig 工作。它感觉比 C 好得多，而且没有那么多陷阱。 ## 离开 Rust Zig 不断破坏我的代码。我厌倦了这种变动。作为一名学生，我没有太多时间让我的代码能适应最新版本的语言。在此之前，anyzig (https://github.com/marler8997/anyzig) 还没有使得在同一个系统上处理多个 Zig 版本变得简单。我经常在特定项目之间间隔数月。当我回来时，我不得不进行我不理解的大规模重构才能让它们重新工作。 Zig 的生态系统也不成熟。作为一名新手程序员，我没有能力独自实现一切。任何东西的库都很少，能够教我的示例也很少。标准库在不断变化。每次我认为我理解了其抽象的工作方式时，它们就会改变。默认文档不稳定也无济于事。 于是我去投奔 Rust。那时，Rust 已经稳定多年，拥有强大的生态系统。学习它很痛苦——有好几次我想放弃——但一旦学会，它确实工作得很好。这对我而言是无价的。一种快速、低层次的编程语言，具有我需要的表达能力，且没有不稳定性的代价。它还迫使我发展了一种内存模型，这对那些内置检查较少的语言也很有帮助。 作为额外好处，在代码不 panic 的情况下，我能够编写没有隐藏控制流或垃圾收集器的可重用代码。虽然它隐藏了内存分配，并使得与 C 交互变得困难，但它几乎让我回到了 Zig 吸引我的地方。 我爱 Rust。直到今天我依然享受使用它工作。这些抽象带给我快乐。不幸的是，我对项目的一些发展方向感到担忧。 ## 为何回归 Rust 仍然不完美。虽然它提供了我在编程语言中寻找的许多特性，但它并不是制作我想要的可重用程序的最理想选择。FFI 很困难。交叉编译很烦人。隐藏的、不可失败的内存分配困扰着我。被束缚在 LLVM 上，它将需要很长时间（如果有的话）才能像 C 一样支持那么多平台。 此外，它的治理仍然让我恼火。它有多个巨大的企业基金会成员 (https://rustfoundation.org/members/)，这些成员几乎肯定会影响 Rust 的开发方式。当世界上最大的公司每年给你数十万美元时，你可能不想得罪他们。 抛开这些不谈，我原本愿意接受这些，直到“vibecoding”的祸害冲击了开源社区。令我惊恐的是，许多软件项目都在接受 LLM 生成的代码。我曾以为 LLM 在开发者中并不受欢迎。我以为只有那些被雇主强迫的人才会使用它们。 当这种情况发生时，维护者和用户都撰写或要求 LLM 政策。Zig 完全禁止了它们 (https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-policy)。与此同时，Rust 则花了些时间。他们做了一些调查，社区普遍情绪是反 LLM 的，但他们还没有准备好制定官方政策。 当他们最终提出一个提案 (https://github.com/rust-lang/rust-forge/pull/1040) 时，其中包含了臭名昭著的版规： > 本 PR 下的任何评论不得提及以下话题： > - LLM 的长期社会或经济影响 > - LLM 的环境影响 > - 任何与 LLM 输出版权状况有关的内容 > - 对使用 LLM 的人进行道德评判 该规定在遭到反对后被移除，但这一情况的存在本身就让我对 Rust 项目未来的信任受损。我爱这门语言，但对它的治理感到沮丧。 该政策本身没有问题。它几乎完全限制了 LLM。它减少了大部分劣质内容。虽然没有 Zig 的政策那么严格，但也够用。但这次经历促使我时隔几年后再次认真探索 Zig 这门编程语言。 ## 2026 年的 Zig 我注意到的第一件事是这门语言仍然不稳定。当我尝试使用在网上找到的 0.16.0 示例开始时，我发现它们已经过时了。我了解到在 Zig 中提高效率的最佳方法是保留一份标准库源代码副本并熟悉它。 我对 Zig 的稳定性不抱幻想。Zig 0.17.0 即将发布。它将破坏每个项目的构建系统。我理解维护者打算转向稳定化，而这些破坏是这个过程的一部分。 幸好，这门语言自 2020 年以来变化并不太大。我发现我的大部分直觉仍然有效。库中的一些东西被重做了，但代码易于阅读，我很快找到了方向。我相信今天的 Zig 代码在六年后仍然会很容易识别。 我注意到的另一件事是 Zig 现在有了一个包管理器。我相信在我离开时它还在开发中。我记得使用 git 子模块进行依赖管理。内置的工具要好得多。项目可以通过 git 和 tarball 定义依赖。vendor 操作毫不费力。一切都正常运作。 生态系统仍然不广泛，但这从来都不是 Zig 的目标。Zig 项目没有官方包注册表是有原因的。我们不需要另一个 NPM 或 crates.io。对我来说，Zig 达到了完美的平衡。 ## 但内存不安全！ 我知道 Zig 没有提供与 Rust 相同的内存安全保证。不幸的是，这是他们为了简洁而做出的取舍。Rust 的仿射类型的复杂性不值得其安全收益。 这并不是说他们放弃了安全。Zig 比不安全 Rust 更安全 (https://zackoverflow.dev/writing/unsafe-rust-vs-zig/)。所以当你发现自己处于必须编写不安全 Rust 的情况时，Zig 可能是一个更好的选择。 Zig 也在努力使语言更加安全。他们的方法侧重于发布模式而不是 unsafe 代码段。目前，Zig 的 ReleaseSafe 模式在断言失败时崩溃并初始化所有内存。但 Andrew Kelley 有兴趣进一步推进 (https://lobste.rs/c/u41yfq)，推出带有类似 Fil-C (https://fil-c.org/) 功能的 ReleaseSafe。虽然这不能提供 Rust 的编译时内存安全性（假设你避免使用 `unsafe`），但这也不会像某些人暗示的那样成为死亡螺旋。 内存安全是一个光谱。没有一种内存安全方法在所有情况下都最有效。Zig 的方法是让 ReleaseSafe 在运行时尽可能安全，然后进行测试和模糊测试以确保正确性。任何未经检查的非法行为都应该在那时被发现。在证明其正确性之后，二进制文件应该可以在其他发布模式下安全发布。 与 Rust 的模型相比，这种方法有一些缺点，但它并非严格劣势，尤其是当 Zig 追求 Rust 只能梦想的简洁性时。有许多编程语言，你可以选择最适合你用例的那一种。如果编译时内存安全性值得复杂类型系统和长时间编译的代价，那么就去用吧。但这并不适用于每个人在每种情况下的需求。 Zig 的内存安全模型延伸到其断言哲学。Zig 没有在 ReleaseFast 中禁用断言，而是信任你已经完成了必要的测试来证明你的断言是正确的 (https://kristoff.it/blog/fix-your-asserts/)，并且那些路径不可达，从而允许 Zig 优化代码。 Zig 要求完美，但它提供了实现完美所需工具。 ## 结论 所以，手拿标准库和发布日志，我准备用 Zig 来应对我面临的任何软件问题。当我不想处理较低层次的细节时，我会求助于我选择的脚本语言 (https://gracefulliberty.com/notes/scheme-is-a-hoot/)，但 Zig 将是我未来软件的动力源泉。 我不一定会一直使用 Zig。当我需要它的稳定性或其类型系统时，我可能会转向 Rust。也有可能我完全改变对 Zig 方法的看法。多种语言可以并且应该共存。 但 Zig 代表了一种与我产生共鸣的软件愿景。软件关注用户，不是通过忽视软件质量，而是通过拥抱它。人们应该得到可靠、强大的软件。在 LLM 时代 (https://gracefulliberty.com/articles/pragmatic-llms) 尤其如此，因为精心制作的软件正变得罕见，人们被压力迫使接受日益恶化的劣质内容。