The Zig Journey / Zig 之旅

A couple of weeks ago I attended Zigtoberfest, a single-day conference organized in Munich. I was offered the privilege to give some introductory remarks at the beginning of the day, and I chose to spend my time offering the audience some suggestions on how to approach Zig both as a project and as a community, divided in three tiers, aimed respectively at newcomers, intermediate, and advanced users of Zig. 几周前，我参加了在慕尼黑举办的单日会议 Zigtoberfest。我有幸在会议开始时发表了开场致辞，我选择利用这段时间为听众提供一些关于如何从项目和社区两个层面接触 Zig 的建议，并将其分为三个阶段，分别针对 Zig 的初学者、中级用户和高级用户。

I’m not going to repeat everything in this blog post, but I want to highlight the point at the core of my speech: the Zig journey. Coincidentally, this post might also help answer some questions from people who don’t really understand what is the point of Zig in light of {Go, Rust, Modula-2, Mojo, LLMs, …}. 我不会在这篇博文中重复演讲的所有内容，但我希望强调我演讲的核心观点：Zig 之旅。巧合的是，这篇文章或许也能帮助回答一些人的困惑，即在 {Go, Rust, Modula-2, Mojo, LLMs, …} 等技术背景下，Zig 的意义究竟何在。

1. Target computers not frameworks / 1. 面向计算机，而非框架

My main piece of advice for newcomers is to learn how to think of a problem as a sequence of operations offered by the target system, as opposed to a composition of dependencies that offer a higher level – but limited, and potentially even wasteful – API. This is an extremely useful skill to train no matter what ecosystem you’re working in, including web development. 对于初学者，我的主要建议是学会如何将问题思考为目标系统所提供的一系列操作，而不是将其视为依赖项的组合——这些依赖项虽然提供了更高级别的 API，但往往受到限制，甚至可能造成浪费。无论你身处哪个生态系统（包括 Web 开发），这都是一项极其有用的训练技能。

Systems programming is a way of modelling software development. It’s not about a category of what you are working on, it’s a way of looking at the problem. An excellent systems programmer fully understands the systems involved. — Andrew Kelley @ Systems Distributed ’23 “系统编程是一种软件开发建模方式。它不是关于你正在从事的工作类别，而是看待问题的一种方式。优秀的系统程序员会完全理解所涉及的系统。” — Andrew Kelley @ Systems Distributed ’23

This is not to say that you should not use dependencies or frameworks, but it is a problem if that’s the only thing you know how to do. Plenty of trivial applications are best solved by gluing dependencies together, but if you ever want to try your hand at creating something innovative, then you will want to have full control over the core functionality of your program, in order to provide your users with a truly new and thoughtfully designed experience. 这并不是说你不应该使用依赖项或框架，但如果你只会这一种方法，那就有问题了。许多琐碎的应用程序通过拼凑依赖项就能很好地解决，但如果你想尝试创造一些创新的东西，你就会希望完全掌控程序的核心功能，从而为用户提供真正新颖且经过深思熟虑的设计体验。

2. Design code behavior in depth / 2. 深入设计代码行为

If the previous advice was to scrutinize the functional requirements of your applications, now my advice for intermediate Zig users is to take charge designing everything else. If your application has some important C/C++ dependencies, it makes a big difference if users are required to go install them on their own, compared to you providing them directly in your Zig build script. 如果之前的建议是审视应用程序的功能需求，那么现在我给 Zig 中级用户的建议是：接管其他所有方面的设计。如果你的应用程序有一些重要的 C/C++ 依赖项，那么要求用户自行安装，与你在 Zig 构建脚本中直接提供它们，这两者之间有着巨大的区别。

In the former case your application has a de-facto dependency on package managers (apt, brew, winget, etc) and is going to break whenever a package maintainer changes something in the way they package the dependency (e.g. the version, or a feature toggle). This is also what prompts overuse of containers in some ecosystems, while Zig makes it possible to achieve the gold standard of having your application build for all systems, from all systems, just by running zig build. 在前一种情况下，你的应用程序实际上依赖于包管理器（apt、brew、winget 等），一旦包维护者更改了打包依赖项的方式（例如版本或功能开关），你的程序就会崩溃。这也是导致某些生态系统中过度使用容器的原因，而 Zig 则通过运行 zig build，实现了让你的应用程序在所有系统上、从所有系统进行构建的黄金标准。

To help with that, I’ve created All Your Codebase (GH, CB), an organization that collects and collectively maintains build scripts for C/C++ projects. This is just one example of designing code behavior in depth. Other examples include improving efficiency, removing unnecessary heap allocation, and proper fuzzing. 为了解决这个问题，我创建了 All Your Codebase (GH, CB)，这是一个收集并集体维护 C/C++ 项目构建脚本的组织。这只是深入设计代码行为的一个例子。其他例子还包括提高效率、消除不必要的堆分配以及进行适当的模糊测试。

3. Make perfect software a reality / 3. 让完美的软件成为现实

The advice for advanced Zig users is to simply find a project that you are passionate about, and to bring it to the finish line. Perfection in this context means that you have fully explored the scope you decided to tackle with your application, that you have full ownership of the core functionality offered to your users, and that there are no more significant non-functional improvements left for you to make. 对于 Zig 高级用户，我的建议很简单：找到一个你热衷的项目，并将其带到终点。在这种语境下，“完美”意味着你已经充分探索了你决定通过应用程序解决的领域，你对提供给用户的核心功能拥有完全的掌控权，并且不再有重大的非功能性改进需要你去完成。

Depending on the scope of the project, getting to this point can take multiple years of work, but it is ultimately how you give meaning to all the effort you put into your journey. 根据项目的范围，达到这一目标可能需要多年的努力，但这最终是你为旅程中投入的所有心血赋予意义的方式。

In Conclusion / 总结

What I just described is not something unique to Zig. You can (and should!) follow the same path in other ecosystems, but Zig is both a toolchain and a community that deliberately aims for helping you make progress in this journey. While neither the toolchain nor the ecosystem is fully mature yet, depending on your personal sensibilities and willingness to be an early-ish adopter, Zig might already be the best way for you to become a more impactful software engineer. 我刚才描述的内容并非 Zig 所独有。你可以在其他生态系统中遵循同样的路径（而且应该这样做！），但 Zig 既是一个工具链，也是一个社区，它刻意旨在帮助你在这一旅程中取得进步。虽然工具链和生态系统都尚未完全成熟，但根据你的个人偏好和成为早期采用者的意愿，Zig 可能已经是你成为更具影响力的软件工程师的最佳途径。

In “Hello Systems” I talk about how much harder it is to write a feature-complete static site generator in Python compared to a low level language like Zig. This is because once you go past the most superficial layer of functionality (turning Markdown into HTML), all the abstraction involved with Python makes it impossibly hard to fine tune concurrency and many other things. 在《Hello Systems》中，我谈到了用 Python 编写一个功能完备的静态网站生成器，比使用像 Zig 这样的底层语言要困难得多。这是因为一旦你超越了最表层的功能（将 Markdown 转换为 HTML），Python 所涉及的所有抽象层使得微调并发性以及许多其他事情变得极其困难。

Thinking that high level programming languages are always the easiest way to create software is believing in a falsehood that in turn leads to over-reliance on dependencies, and that ultimately disconnects you from the reality of what the machine can do. Learning to understand systems in depth will make you not only better at using dependencies, but also at steering LLMs. This might seem counter-intuitive at first glance, but it’s kind of an obvious truth: how can you evaluate the quality of what you get from a dependency or an agent, if you have no idea of what’s even possible? 认为高级编程语言总是创建软件的最简单方式是一种谬论，这会导致对依赖项的过度依赖，并最终让你脱离机器实际能力的现实。深入理解系统不仅会让你更善于使用依赖项，还会让你更善于驾驭 LLM。这乍看之下似乎有悖常理，但其实是一个显而易见的真理：如果你连什么是可能的都不知道，又怎么能评估从依赖项或 AI 代理那里获得的内容的质量呢？

At the end of my speech at Zigtoberfest, I asked the audience to raise their hand if they felt they were making good progress in their Zig journey, and pretty much the entire room (of ~100 people) raised their hand with confidence. This was a delightful moment for me because it shows that our collective effort (Andrew, core team, event organizers, etc) is truly making the Zig Software Foundation’s mission a reality. 在 Zigtoberfest 的演讲结束时，我请听众举手示意，如果他们觉得自己在 Zig 之旅中取得了良好的进展，几乎整个房间（约 100 人）都自信地举起了手。这对我来说是一个令人愉快的时刻，因为它表明我们的集体努力（Andrew、核心团队、活动组织者等）正在真正实现 Zig 软件基金会的使命。

If you want to hang out with other people who care about furthering their understanding of software engineering, join a Zig Day near you or attend any other Zig event (Software You Can Love Vancouver is next month!). Lastly, please consider supporting our non-profit foundation. 如果你想与其他人交流，共同深入理解软件工程，请参加你附近的 Zig Day 或任何其他 Zig 活动（下个月在温哥华举办的 Software You Can Love 就是其中之一！）。最后，请考虑支持我们的非营利基金会。