【Zig 日报】What Zig felt like, coming from Rust

[ZigCC Forum]

原文链接：https://github.com/zigcc/forum/issues/365

What Zig felt like, coming from Rust | besok 是一份由经验丰富的 Rust 开发者撰写的深度体验报告，对比了 Zig 和 Rust 在构建 JSONPath 实现时的差异。以下是整理的关键要点：

---

IDE 支持：从束缚到解放

• 现状： Zig 目前缺乏成熟的 IDE 支持（语法高亮和基础补全为主），开发者被迫回归命令行。
• 意外收获： build.zig 提供了优秀的 CLI 集成（测试、合规检查等），工作流反而更简洁。这促使作者转向更精简的终端环境 (Helix + Alacritty + Zellij)。

---

扁平结构：习惯的挑战

• Zig 的倾向： 鼓励扁平结构，不鼓励过早或过度使用嵌套文件夹。文件拆分需权衡必要性（“为什么拆分？”）。
• 对比 Rust： Rust 项目早期就习惯采用多层结构。
• 项目启示： 在 JSONPath 项目中，Zig 仅需 5 个文件（vs Rust 的 15+ 文件），未遇到结构瓶颈。反思：过度结构化可能是习惯，而非项目必需。

---

测试：简洁但需手动管理

• Zig 方式： 测试写在 build.zig 中指定。劣势：单文件内联测试易导致文件臃肿；需手动管理测试生命周期。
• 对比 Rust： Rust 的内联测试和集成测试分离更成熟。
• 核心问题： Zig 的手动内存管理（allocators）增加了测试复杂性，尤其需谨慎处理错误路径的清理。

---

函数式范式的碰撞

• Rust 优势： 天然支持函数式特性（模式匹配、ADT、迭代器组合子、不可变性等）。
• Zig 的现实： 无原生函数式支持。代码必须转向：
  • 就地修改 (Mutation)：替代不可变 Monad（如 Data<T> 的 flat_map）。
  • 显式迭代：替代高阶函数（filter/map）。
  • 深拷贝分叉：替代不可变状态分支（State::reduce）。
• 结果： Zig 代码更命令式、冗长，作者认为可读性低于 Rust 版本。

---

手动内存管理：显式但繁琐

• Zig 核心特征： Allocators 无处不在，需手动管理生命周期 (init/deinit, errdefer)。
• 挑战场景（需逐一处理）：
  1. 遗忘清理 (Leak): 通过 TestingAllocator 检测。
  2. 错误路径泄漏 (Error Leak): 需 errdefer 兜底。
  3. 双重释放 (Double Free): 跨函数所有权转移易错。
  4. 孤立分配 (Orphaned Allocation): 中间步骤失败需 errdefer 保护。
• 对比 Rust： Drop Trait 自动处理作用域结束时的清理（包括错误路径），所有权系统从根本上防止此类问题。

---

生态与标准库

• 生态现状： 库资源稀缺，基础工具（如正则表达式库 mvzr）功能不完整（如缺少 Unicode 属性转义）。
• 标准库： API 尚不稳定，版本间有变动。

---

总体印象与潜力

• 优势： Zig 现代、高效、构建系统优秀，扁平结构有价值。
• 挑战： 年轻语言（API 不稳定、生态薄弱），强制命令式范式，内存管理认知负担重。
• 展望： 作者认可 Zig 作为 C 语言继任者 的潜力，并计划持续参与生态建设。

---

结论： Zig 以其底层控制、简洁构建和特定优势（如扁平结构）吸引了作者，但与 Rust 相比，其在开发效率（IDE/内存管理）和表达力（函数式特性）上仍有差距。这是一次基于实践的技术选型探索，展现了 Zig 在特定场景（如替代 C）的竞争力，同时也凸显了 Rust 在高阶抽象和安全性上的优势。

加入我们

Zig 中文社区是一个开放的组织，我们致力于推广 Zig 在中文群体中的使用，有多种方式可以参与进来： 1. 供稿，分享自己使用 Zig 的心得 2. 改进 ZigCC 组织下的开源项目 3. 加入微信群、QQ 群、QQ 频道、Telegram 群组、Google Groups 与更多 Zig 爱好者交流