Zig：所有包管理功能已从编译器移至构建系统

原文 ↗ Hacker News 讨论 ↗

Zig 的开发理念与 LLM 的角色

  • 一些评论者认为 Zig 证明了“软件作为一门手艺”仍然存在，重视经过深思熟虑的人类设计，而不是 LLM 生成的语言。
  • LLM 被视为很适合小型 DSL 或局部任务，但不适合面向未来几十年的核心语言/编译器代码。
  • 担忧包括：LLM 编写的代码冗长、意图不清，而且在关键系统中审查它很困难。
  • 也有人表示在业务代码库中大量且成功地使用了 LLM，尤其是在明确、防御性强、低抽象的风格下，这让 AI 生成的代码更容易审查。

构建系统、WebAssembly 与沙箱化

  • 大家对将 Zig 的构建系统迁移到 WebAssembly VM 中、以便对 build.zig 进行沙箱化的计划感到兴奋。
  • 支持沙箱化的观点：
    • 限制不受信任的构建脚本能做的事情，尤其是在编辑器/LSP 自动运行它们时。
    • 便于实现细粒度的权限代理，并更容易审计哪些依赖需要额外能力。
  • 怀疑的观点：
    • 如果构建脚本仍然可以启动任意进程（例如 cmake），那么沙箱化在某种程度上只是“安全表演”。
    • 一些人认为，全环境/容器级沙箱化（bwrap、devcontainers、隔离服务器）更合适。
  • 反驳：安全并非非黑即白；部分沙箱化仍然会提高门槛并改善可复现性。

包管理与多语言构建的担忧

  • 有人遗憾每种语言都在发明自己的包/构建系统；他们更希望有一个优秀的、支持多语言、跨平台的系统。
  • Buck 和 Bazel 被提为最接近这一理想的方案，但也被认为受其出身所累。
  • 讨论的焦点还包括：构建系统是否也应该充当编译器前端，还是只负责协调多个独立工具链。

C/C++ 包管理与依赖文化

  • 对缺乏标准 C++ 包管理器的看法不一：
    • 优点：迫使人们谨慎选择依赖并手动更新，避免出现像 cargo 那样有数百个传递性 crate 的树。
    • 缺点：导致每个大型 C++ 项目都在重复实现基础组件（JSON、异步等），而且往往做得很差。
  • Conan 和 vcpkg 被提及为事实上的解决方案，但并未被普遍接受。

设计错误、演化与 Zig 的包管理迁移

  • “油箱里加了散热器冷却液”的类比被用来批评那些后来又撤回早期设计选择的语言（例如将包管理移出编译器）。
  • 支持者认为，早期紧耦合是一种务实的交付和迭代方式；在 1.0 之前解耦被视为负责任的演进。
  • 一些人担心现代语言忽视历史经验；另一些人强调，语言设计本质上就是迭代性的，而且极其困难。

面向用户的影响（例如 @cImport）

  • 一位评论者将包/构建方面的变化与之前移除 @cImport 联系起来，认为这是 UX 层面的损失，不过其他人澄清其动机是分开的（LLVM/libclang 解耦 vs. 包管理重构）。