21CTO导读：一位软件工程师重返Zig，并且将几个项目全部用Zig重写。

Anna Liberty 在多年搁置之后，用四个月的时间重新编写 Zig 程序。她用Zig做了三个项目，还参加了由Zig语言创造者 Andrew Kelley 出席的 Zig Day 聊天会议，她确信 Zig 是自己的首选工具——尽管还和一些语言存在一点差距，让她在稳定性不可妥协时仍会求助于 Rust。

Liberty 的第一个项目 snurl 面向 smallnet（Gemini、Finger、Gopher、Spartan），其作为 curl 的替代品。早期的摩擦出现在 Zig 内置的 fuzzer 上——它在默认的 zig init 模板中展示过，结果却并不完整。她还做了一个未发布的 TUI 打字竞赛程序，以及一个使用 raylib 的 n-body 恒星演化模拟器。

八月在西雅图举办的 Zig Day 上——由于人数超过预期，活动从 Bellevue 移到了 Bothell——Liberty 与 Evin Yulo 结对编程，将 Zig 标准库的 TLS 集成到 snurl 中，并与 Kelley 简短聊了聊 fuzzer项目。

Liberty 所认为Zig特别好用的地方：

• anyzig
  在多个项目间管理多个 Zig 版本（master 和 0.16.0），不过它会破坏带有 build.zig.zon 的外部目录，导致一次性脚本的自动格式化失效。
• 显式的分配器和 IO 参数：
  每个分配内存或触碰操作系统的函数都必须携带参数。Liberty 更喜欢这样，而不是 Odin 的隐式上下文和 Rust 那些隐藏的、不会失败却在内存耗尽时 panic 的分配方式。她写道：“一个函数是否分配内存一目了然，而且很难不小心传错分配器。”
• Comptime
  统一了元编程与预计算。
• 构建系统
  已被 Uber 等知名公司用于非 Zig 代码库；在 Cargo 难以处理的地方，它能干净地集成代码生成。
• 依赖文化
  倾向于避免依赖。她的 Zig 程序大多只有一两个直接依赖，间接依赖为零。Rust 项目为了 JSON、反射、随机数和错误处理这些基础功能，通常会拉入几十个传递 crate——而这些功能都在 Zig 的标准库中。
• 错误处理
  try和错误联合返回值（!Type）胜过 Rust 用 Box

• 增量编译
  （zig build --watch -fincremental）只重新编译改动的单元，一直到链接，在大型代码库上也几乎感觉不到延迟。而Rust 那 10 秒的增量循环容易让人分心。Zig 的设计成就了这一点；Rust 的稳定性保证限制了这一点，目前仅支持 x86_64 Linux/macOS。
  
  

有待改进的地方：

• 稳定性：标准库的变动仍是 1.0 的头号障碍。当需要稳定的生态系统时，Liberty 仍会选择使用 Rust。
• 生命周期诊断：从代码块返回栈上分配的缓冲区可以编译通过，但在未来版本中会出问题。她希望在 debug 模式下失败，或在函数返回时让内存失效。
• 文档：文档注释稀少，示例程序不多。Liberty 和一位合作者没能让 stdlib 的 TLS 在 snurl 中跑通。知识存在于社区频道（她是 Matrix 聊天室的管理员）而非文档里。
• Comptime 分配器：目前没有分配器能在编译期工作，导致即便嵌入二进制的静态数据也得在运行时解析 JSON。一个无分配的 JSON 解析器已在计划中。
• 引导：编译器由一份检入仓库的 WASM blob 构建，它把完整的编译器编译成 C，再由系统 C 编译器完成剩下的工作。Debian 这类发行版按其指导原则无法打包 Zig，因为该 blob 不是源码。一个从源码开始的引导过程（很可能是用 C 重新实现）正在期待Zig 1.0 稳定版。

Liberty 正在把 ReTangled 项目从 Rust 移植到 Zig，以摆脱依赖膨胀并充分利用构建系统。她计划向上游贡献代码，并参加下一步在西雅图举办的 Zig Day 会议。

作者：洛逸

参考：

Zig 官网：https://ziglang.org 

anyzig：https://github.com/anyzig/anyzig

Ryan Hendrickson 的 Zig Day Seattle 报道：

https://ryan.hendrickson.dev/posts/zig-day-seattle-2024/

https://gracefulliberty.com/articles/four-months-of-zig