Zig v0.17.0

原文 ↗ Hacker News 讨论 ↗

Zig v0.17.0 引发了复杂反应：许多人称赞它的设计、不断增长的真实世界采用和广泛的目标平台支持，而另一些人则对其不稳定、功能推出缓慢以及在 1.0 之前的破坏性变更感到不满。一个主要争议点是项目对 LLM 辅助贡献到编译器和官方空间的严格禁止；支持者认为这是一个人手紧张的核心团队所需的质量控制，而反对者则认为这具有敌意、不切实际，或会疏远贡献者。像暂时禁用 LLVM 循环向量化、延后事件驱动 I/O，以及关于内存安全的长期计划等技术问题，也影响着人们对 Zig 成熟度和前景的判断，并将其与 Rust、Odin 和 C3 等语言进行比较。

项目状态与方向

  • 许多评论者认为 Zig 正在稳步推进：发布节奏正常、资金状况不错，并且已有真实世界的采用者（例如数据库、终端）。
  • 也有人认为它“像一个业余项目”：0.x 期间频繁破坏性变更、工具链不稳定，以及通往 1.0 的路径缓慢，让人很难依赖它。
  • 有人预计要再经过几个版本和几年后才会到 1.0；也有人愿意等待，认为 1.0 之前的破坏性变更是有意为之，以避免以后出现更大的破坏。

AI / LLM 政策与 bug 报告

  • 官方政策禁止在 Zig 官方空间中出现由 LLM 编写或 LLM 建议的内容：不允许 AI 写的评论，不允许“用 LLM 找 bug”，也不允许在 bug 报告中讨论聊天机器人使用情况。
  • 支持者认为这很务实：核心维护者人数很少，已经被低质量的 AI 垃圾内容淹没，希望收到的是人类撰写、可复现的报告。
  • 批评者称其“像邪教”或“不成熟”，并认为：
    • 因为涉及 AI 就忽视有效的 bug 报告，是一种浪费。
    • 该政策会让那些在自己项目中负责地使用 AI 的人望而却步。
  • 一位核心成员澄清：
    • 在你自己的 Zig 代码中使用 LLM 是可以的。
    • 对于 bug 报告：只要提供最小复现/预期/实际结果；不欢迎基于 AI 的根因分析。
    • 内部对此存在一些分歧，也有较为细腻的个人看法。
  • 有人引用了一次演讲，其中核心领导层对 LLM 作为未来找 bug 工具表现出“逐渐接受”的态度，但前提是先经过大量传统测试/模糊测试；重新评估被推迟了几年。

社区文化与治理

  • 有些人表示互动积极、讨论认真，并认为这项政策对一个超负荷的团队来说是合理边界。
  • 另一些人描述了敌对经历（例如在 Zig 仓库中被拉黑），并觉得决策不透明，且受到对 AI 用户的个人反感驱动。
  • 对社区在实践中是否“去中心化”存在争论，因为其自上而下的规范和沟通风格都很强。
  • 几位评论者表示，由于他们感知到的不成熟，以及对前协作者和供应商公开的尖刻批评，他们不会为 Zig 捐款或采用它。

0.17.x 时间线中的技术点

  • LLVM 升级：由于 LLVM 22 的一个问题，0.16.0 和 0.17.0 都禁用了循环向量化；无法轻易回移该修复，也不能直接跳到 LLVM 23。计划在 0.18.0 中重新启用。
  • 一些用户在升级后，在可向量化工作负载上看到约 10–15% 的性能回退；他们怀疑这是由于向量化关闭所致。
  • 事件驱动 IO / io_uring：一个尝试曾经“几乎”准备就绪，但后来被移除；本版本中没有包含。
  • 人们对以下内容感到兴奋：
    • 广泛的目标平台支持，可能在某些方面超越 C。
    • 即将到来的 SPIR-V 和 WebGPU 工作流。
    • 未来无栈协程 IO 和集成式模糊测试。

与其他语言和生态的比较

  • 一些人认为 Zig 正在“C++ 化”（复杂度不断上升），因此转而探索 Odin 和 C3。
  • 另一些人称赞 Zig 的设计是他们用过的最好的设计之一，并把它的理念比作那些核心小而强大的语言（例如 Haskell）；但也有人强调 Zig 和 Haskell 在文化和技术上都相差甚远。
  • 人们期待未来会出现“Rust vs Zig”的争论，尤其是在外部工具为 Zig 带来更强内存安全保证的情况下。