Zig 的增量编译内部机制

Zig 中的增量编译

• 当前的增量模式只适用于 Zig 的自托管后端（不包括 LLVM），主要是 x86_64，目前实际上基本上是“仅限调试构建”。
• 未来计划：为自托管后端加入优化流程，并最终支持某种形式的 release 构建；但跨函数优化（例如内联）与这种模型在根本上是冲突的，因此仍会受到限制。
• Zig 的语言设计随着时间不断调整（有时也引发争议），其目的就是让细粒度增量编译和语义分析变得可行。

C 编译与对 LLVM 的依赖

• 在混合 Zig/C 项目中，增量重编译只适用于 Zig 源码；C 通过 LLVM 编译，且不会以同等粒度被缓存。
• 存在一个基于 Zig 的 C 编译器（Aro/arocc），用于 translate-c（头文件转换），但还不是通用的 C 后端。更长期的 C 编译计划仍在设计中。

为什么是一个大二进制和增量链接

• 有人质疑为什么 Zig 要修补一个大型调试二进制，而不是组合成许多小的共享库。
• 回应：
  • Zig 使用单一编译单元模型；独立文件只是组织方式，不是编译边界，所以无论哪种方式，大部分增量工作（解析、语义分析）仍然需要做。
  • 拆成很多共享库，主要只是把工作从静态链接器转移到动态加载器，会损害运行时启动速度；对数百到数千个共享库的实测实验表明会有明显开销。
  • 增量链接被承认很复杂，但被认为是更好的权衡；关于损坏的担忧将通过缓存分离、损坏检测和安全取消来处理。

Rust、其他编译器与编译时间

• 讨论中多次将其与 Rust 作比较：
  • Rust 已经有增量编译，但受语言复杂性影响（宏、过程宏、名字解析、单态化泛型），并且仍沿用传统的“先编译库再链接”模型。
  • Rust 方面也在持续改进增量行为（例如更细粒度的查询、“只重新链接，不重新构建”），但重构架构很难。
  • 有人认为很多语言即使只使用了库的一小部分，也还是会编译整个库，造成工作浪费；Zig 的按需驱动模型被认为更简洁。

内存安全与语言取舍（Rust、Zig、Java、Fil-C）

• 一派把“默认内存安全，并提供显式逃逸口”视为基线（Rust/Java 风格）；另一派则认为真正重要的是“有用”的安全子集，以及整体权衡（复杂度、性能、迭代速度）。
• Zig 被认为比 C 有所改进（尤其是在空间安全工具方面），但仍然是“默认不安全”；一些人认为这与其目标和工具优势相符，而另一些人则认为缺乏完整内存安全是致命缺陷。
• 讨论进一步比较了 Rust、Zig、Java、C、ATS 和 Fil-C：
  • 对“内存安全语言”应如何定义、Rust 的位置是否只是“入场门槛”，以及显式 safe/unsafe 边界究竟有多大价值，存在分歧。
  • Fil-C 被讨论为一个实验性的 C 变体，使用 capability 和运行时来阻止许多利用方式。支持者强调其更强的保证；批评者则指出其运行时开销、依赖 trap 而非编译期证明、平台限制以及实现尚不成熟。
  • 多位参与者强调，不同项目和团队会理性地选择安全性、复杂度和性能谱系上的不同位置。

Hello World 与易用性

• Zig 官方的“hello world”在一些人看来比 C 风格示例更啰嗦。
• 辩护观点：
  • 它“更正确”：显式的 IO 句柄、显式错误处理，以及与 Zig IO 模型的集成。
  • 也存在更简单的变体（例如用 std.debug.print 输出到 stderr）用于快速演示；这段更啰嗦的示例是刻意把真实世界的问题显露出来，而不是把它们隐藏起来。