本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Four Months of Zig

Four Months of Zig 2026-10-27 · 15 min · #computing It has been about four months since I returned to Zig after being absent for a few years. In this time, I have written some software in Zig and reengaged with the community, online and in person. I decided to share some of that experience, including what I have liked about Zig so far and what I haven’t. I’ll include some comparisons to Rust along the way since that was my previous go-to language.

距离我离开几年后重返 Zig 社区已经过去大约四个月了。在这段时间里，我用 Zig 编写了一些软件，并在线上和线下重新与社区建立了联系。我决定分享一些心得，包括目前为止我对 Zig 的喜爱之处以及不满之处。由于 Rust 是我之前首选的编程语言，我也会在文中加入一些与 Rust 的对比。

Projects

The first project I started in Zig was snurl. It is a library for interacting with the smallnet (Gemini, Finger, Gopher, Spartan, and such). My goal has been to provide an alternative to curl for the smallnet, with similar testing and fuzzing requirements but on a smaller scale. I wanted to roughly follow TigerStyle insofar as it made sense for the project. Something I ran into early on was that the fuzzer didn’t actually work. When getting excited about fuzzing in my last post, I didn’t realize that the feature had not yet been completed. This isn’t surprising, considering Zig’s status, but it was disappointing, especially since the fuzzer is demonstrated in the generated main.zig file provided by zig init. After this, I wrote a two programs which I have not published yet. The first is a small TUI typer racer. It was simpler than I expected to get a minimum version working so far. The second is an n-body simulator with stellar evolution using raylib.

我在 Zig 中启动的第一个项目是 snurl。这是一个用于与 smallnet（Gemini、Finger、Gopher、Spartan 等）交互的库。我的目标是为 smallnet 提供一个类似 curl 的替代品，具备类似的测试和模糊测试需求，但规模较小。在项目合理的范围内，我希望大致遵循 TigerStyle。我早期遇到的一个问题是模糊测试器实际上无法工作。在上一篇文章中对模糊测试感到兴奋时，我并没有意识到该功能尚未完成。考虑到 Zig 目前的状态，这并不令人惊讶，但确实令人失望，尤其是因为 zig init 生成的 main.zig 文件中还演示了模糊测试器。此后，我编写了两个尚未发布的程序。第一个是一个小型 TUI 打字竞速游戏，实现其最小可行版本比我预期的要简单。第二个是使用 raylib 编写的带有恒星演化功能的 N 体模拟器。

Zig Day

The most exciting opportunity in the last few months was the chance to go to a local Zig Day. I learned of Zig Day Seattle occurring on Lobsters on August 20th. I was ecstatic to learn that there was a Zig Day in my area. Then I saw Andrew Kelley would be there and became more excited. Zig Days are local meetups where people interested in Zig hang out, work on their projects together, and talk about Zig. For this Zig Day, I decided to work on snurl. A friend, Evin Yulo also decided to attend. The event itself occurred in the Bothell library, moved there from the Bellevue library after so many people signed up that capacity was overwhelmed. Having the creator of Zig at the event will do that. I love the format of these Zig Days and I’m glad they are a part of the community. Since they are run by local groups, it gives the whole Zig community a more interconnected feeling. It’s a way to interact with other people who are interested in Zig in person. And, in this case, the creator of Zig itself. I got the chance to talk with other programmers about their projects. Hopefully some ideological cross-pollination occurred that will make all our projects stronger. I ended up working on snurl with evin, who started work on integrating Zig’s standard library TLS implementation as alternative backend. I also briefly talked with Andrew Kelley. I hope Zig’s built-in fuzzing gets fixed sometime soon! Ryan Hendrickson wrote an excellent article outlining more of the events of that day from his perspective if you want more details. I will definitely be attending Zig Day Seattle again in the future. I may even head down to Portland to catch one before the next local one comes around. I enjoy the opportunity to connect with other people interested in Zig and its values.

过去几个月里最令人兴奋的机会是参加了当地的 Zig Day。我在 Lobsters 上得知 8 月 20 日在西雅图有 Zig Day，得知我所在的地区有这样的活动，我感到非常激动。后来看到 Andrew Kelley 也会出席，我更加兴奋了。Zig Day 是当地的聚会，对 Zig 感兴趣的人们聚在一起，共同开发项目并交流心得。这次 Zig Day 我决定继续开发 snurl。我的朋友 Evin Yulo 也决定参加。活动地点在 Bothell 图书馆，由于报名人数过多超出了 Bellevue 图书馆的容量，活动才移至此处。Zig 的创始人亲临现场确实会有这种号召力。我喜欢这种 Zig Day 的形式，也很高兴它们成为了社区的一部分。由于它们由当地团体组织，这让整个 Zig 社区感觉更加紧密。这是一种与同样对 Zig 感兴趣的人面对面交流的方式，而且这次还能见到 Zig 的创始人。我有机会与其他程序员讨论他们的项目，希望这种思想上的交流能让我们的项目都变得更强。最终我和 Evin 一起开发 snurl，他开始着手将 Zig 标准库的 TLS 实现集成作为替代后端。我还与 Andrew Kelley 进行了简短交谈。希望 Zig 的内置模糊测试功能早日修复！如果你想了解更多细节，Ryan Hendrickson 写了一篇很棒的文章，从他的视角概述了当天的更多活动。我未来一定会再次参加西雅图的 Zig Day。在下一次本地活动之前，我甚至可能会去波特兰参加一场。我很享受这种与同样关注 Zig 及其价值观的人们建立联系的机会。

What I’ve Liked

anyzig I love anyzig. I’ve had to use zig master and 0.16.0 for different projects, and anyzig has made that doable. Unfortunately, it breaks outside of directories without a build.zig.zon, meaning if you have tooling that requires a zig command to work, it can only occur in project directories. This breaks autoformatting for my one-off Zig scripts. Maybe a default zig version could be provided in that case.

anyzig 我非常喜欢 anyzig。我不得不在不同的项目中使用 zig master 和 0.16.0 版本，而 anyzig 让这一切变得可行。遗憾的是，它在没有 build.zig.zon 的目录外会失效，这意味着如果你有需要 zig 命令才能工作的工具，它只能在项目目录内运行。这破坏了我一次性 Zig 脚本的自动格式化功能。也许在这种情况下可以提供一个默认的 Zig 版本。

IO and Allocators

I know it frustrates some people, but I love the fact that you have to pass IO and allocator parameters to functions in Zig. Allocators I’ll start with allocators, since they’ve been around longer. For each Zig function you have to accept an explicit allocator parameter. This is different from most programming languages which either use a default allocator that may be changed globally or one changed by a local context (see Odin). I like being able to change allocators for different parts of code. You might want an arena allocator for some things but need a general purpose allocator for others. Sometimes a FixedBufferAllocator is all you need to perform an operation. Zig’s style makes this all obvious to handle. I prefer Zig’s system to Odin’s implicit context system since Zig keeps things explicit. It’s clear whether a function allocates memory or not, and hard to accidentally pass in the wrong allocator. This is also superior to Rust’s hidden, infallible allocations that panic when memory is exhausted. They’re working on adding explicit allocations, but this will be yet another feature tacked onto the language rather than something built from the ground up. It’s much easier to reason about programs that allocate memory in Zig.

我知道这让一些人感到沮丧，但我很喜欢 Zig 中必须将 IO 和分配器参数传递给函数这一事实。先从分配器说起，因为它们出现的时间更早。对于每个 Zig 函数，你都必须接受一个显式的分配器参数。这与大多数编程语言不同，后者要么使用可能在全局范围内更改的默认分配器，要么使用由本地上下文更改的分配器（参见 Odin）。我喜欢能够为代码的不同部分更改分配器。你可能在某些地方需要 arena 分配器，而在其他地方需要通用分配器。有时，执行操作只需要一个 FixedBufferAllocator。Zig 的风格使得处理这一切变得显而易见。我更喜欢 Zig 的系统而不是 Odin 的隐式上下文系统，因为 Zig 保持了显式性。函数是否分配内存一目了然，而且很难意外传入错误的分配器。这也优于 Rust 中那些隐藏的、不可失败的分配方式，因为后者在内存耗尽时会引发 panic。虽然他们正在努力添加显式分配，但这将是添加到语言中的又一个功能，而不是从底层构建的东西。在 Zig 中，推理分配内存的程序要容易得多。

IO The IO parameter is even more powerful, even if it is newer. It is well worth the breaking changes required to bring it about (even if I skipped the 0.15.0 -> 0.16.0 transition). In Zig, every function that interacts with the underlying operating system (with caveats) requires an “IO” parameter. This provides the context for input, output, and everything else. Porting Zig to new operating systems is mostly just porting IO. Practically, this is really nice for testing. When testing behavior, you just need to put in a testing IO instance that works as you need it to. You can change the input stream however you want, cause writes to fail, and anything else. Just like with allocation, passing an IO argument makes it clear which programs are pure and which ones are not. You can tell at a glace whether or not a program is going to modify something external. Zig has a really good track record of keeping things simple while also adding powerful features. Instead of adding 100 small features that do slightly different similar things, it tends to provide one major feature that su

IO IO 参数甚至更强大，尽管它更新。为了实现它所需要的破坏性变更非常值得（即使我跳过了 0.15.0 到 0.16.0 的过渡）。在 Zig 中，每个与底层操作系统交互的函数（有例外情况）都需要一个“IO”参数。这为输入、输出以及其他一切提供了上下文。将 Zig 移植到新的操作系统主要就是移植 IO。实际上，这对测试非常友好。在测试行为时，你只需要放入一个按需工作的测试 IO 实例即可。你可以随意更改输入流、导致写入失败或执行任何其他操作。就像分配器一样，传递 IO 参数可以清楚地表明哪些程序是纯函数，哪些不是。你可以一眼看出一个程序是否会修改外部内容。Zig 在保持简洁的同时添加强大功能方面有着非常好的记录。它倾向于提供一个主要功能来解决问题，而不是添加 100 个功能略有不同的小特性。