按示例学习 Zig

原文 ↗ Hacker News 讨论 ↗

“Zig by Example”的现状

  • 目标是 Zig 0.14；评论者指出自那以后已经发生了重大变化（打印/格式化的 “writergate”、构建系统、C 互操作）。
  • 有人说这些示例在当前 Zig 上无法编译；至少已经过时约 2 年，而且“非常简略”/过于简单化。
  • 多位人士断言它看起来是 AI 生成的，因此不适合作为学习材料。

其他 Zig 学习资源

  • 经常推荐：
    • Learning Zig（在线书籍），zig.guide。
    • “Introduction to Zig”（基于项目的在线书籍）。
    • Ziglings（交互式练习；保持与最新版本同步；列在 Zig 官方网站上）。
    • 官方 “Why Zig over Rust/D/C++” 页面。
    • 来自 Tigerbeetle 项目的 TigerStyle 文档，作为风格/最佳实践参考。
    • zigdoc 和 ziglint，再加上 zig fmt 作为工具链。

版本、稳定性和工具

  • 痛点：许多 Zig 项目需要特定的编译器版本；与本地安装版本或不同项目之间不匹配很常见。
  • 有人称这是“重大失误”，也有人说：这还处于 1.0 之前，早期用户本就预期并接受不稳定。
  • 与 Rust editions 的比较，后者允许混合版本；Zig 没有对应机制。
  • 建议的缓解方式：使用版本管理器/隔离环境（mise、Nix、Docker 等）。

是否要学习 Zig（vs. Rust/C/C++）

  • 支持 Zig 的观点：
    • 更简单，更接近 C（带有一些 Go 风格特征），更容易理解机器实际在做什么。
    • 对于偶尔需要下探到底层以追求性能的高阶开发者来说很合适，因为语法简单且工具链/交叉编译能力强。
    • 即便它最终保持小众，这些知识也会迁移到更广泛的系统理解上。
  • 怀疑的观点：
    • Rust 已经覆盖了大部分“现代系统”领域，拥有内存安全和强大的行业推动。
    • Zig 是不安全的、不稳定的，并且可能长期保持小众或走 D 的路线；C 仍是主导性的系统语言。
    • 若要深入学习系统，C（以及也许 Rust）更受青睐；如果你已经很懂 C，Zig 可能显得多余。
    • 有人质疑把语言当作长期“投资”；另一些人则反驳说，保持熟练并跟上变化确实有成本。

语言设计、语法与并发

  • 有些人不喜欢 .{}
    • 在用作参数以及默认/可选/可变参数模式时，被认为很啰嗦。
    • 也有人抱怨必须显式丢弃未使用的返回值。
  • 支持者解释：
    • .{} 是推断出的结构体/元组构造，通常比命名类型更简洁。
    • 显式丢弃是有意为之，用于捕获 bug。
  • 并发模型：
    • 据说总体上类似 Go：使用队列而不是通道，使用 async/并发 API 而不是 go 关键字，并带有类似 select 的构造。
    • 有人遗憾示例材料没有覆盖这些内容。

AI、生态系统与 LLM 支持

  • 关于 AI 存在张力：
    • 有人批评 Zig 项目层面对 AI 生成贡献的禁令，以及“反 AI”群体会损害采用。
    • 也有人澄清，你可以自由使用 AI 编写 Zig 应用；限制主要适用于 Zig 自身的代码库。
  • 为了让 LLM 更好地支持 Zig，建议包括：
    • 与 Zig 语言服务器、本地文档和源码集成，作为权威参考。
    • 构建 MCP 服务器/工具来查询文档、linter、格式化器（zig fmt）和真实代码库。
    • 使用 Zig 项目历史作为基准，来评估 AI 生成的 PR。
  • 也有人表示 AI 让 Rust 更容易上手，并担心 Zig 会错过这波浪潮；另一些人则认为你总可以直接问 LLM，而不必消费 AI 生成的教程。

采用、社区与动机

  • 看法不一：
    • 有人认为 Zig 很有前途，因为工具链、C 互操作和强大的标准库。
    • 也有人预测它会继续保持小众，企业采用有限，社区有时被描述为敌对或精英主义。
  • 使用轶事：
    • 爱好者和非 C/C++ 专业人士把 Zig 用于驱动、FFI 层和个人项目。
  • 有评论者质疑在 AI 时代 Zig 是否还“重要”，并表示自己继续学习它的动力已经流失。