Zig builds are getting faster

Value of Fast Compile Times & Iteration Speed

• Strong disagreement over how important compiler speed is.
• One camp says compile time is dwarfed by thinking, testing, and version control; with hot builds and caching (e.g., Rust) usual rebuilds are already sub‑second, so further gains are diminishing returns.
• The other camp stresses that very fast iteration (1–2 seconds from edit to result) changes how you work: you rely on the compiler as a “spell checker”, run tests more often, and avoid context switches. Slow builds push people to batch changes and mentally simulate code.
• Frontend/web and embedded/FPGA workflows are cited as places where build-time pain is acute; CI and big C++ codebases also feel it.

Zig’s Backend, Incremental Compilation, and Ghostty

• Zig uses LLVM for release builds and its own x86_64 “native” backend for debug on supported platforms.
• The native backend is designed for incremental compilation: only affected functions and binary regions are updated, promising better‑than‑O(n) rebuilds after the first build.
• In the Ghostty case study, earlier measurements used LLVM; later ones use the native backend and are noticeably faster.
• The self-hosted backend is still buggy for some C interop cases (e.g., SQLite) and can’t yet fully build Ghostty without crashes.

LLVM, Cranelift, and “Trap” vs Trade‑off

• Some argue LLVM is a “trap”: quick to bootstrap with many targets and optimizations, but harder to deeply tune final passes and linking, and keeps you tied to C++ and vendor forks.
• Others call it just a trade‑off: codegen is a small part of a compiler, backends can be swapped (Cranelift, GCC), and custom pass pipelines are possible.
• Cranelift is discussed as a fast, safer backend, good for debug builds, but currently substantially slower than optimized LLVM output on benchmarks; too slow for many system‑language release builds.

Comparisons to Other Languages & Compilers

• TCC is frequently cited as the speed baseline; Go, OCaml, Delphi, Turbo Pascal, vlang (via TCC), Nim+TCC, and DMD are mentioned as very fast compilers.
• C++ (especially template‑heavy) and C#/.NET/Java (with heavy tooling like Gradle or EDMX) are criticized for slow builds, though experiences vary widely.
• Some note that Odin and C3, also using LLVM, compile significantly faster than Zig and speculate Zig’s multiple IRs, pervasive comptime, and large generated code as causes.

Interpreters, Debug vs Release, and Games/Embedded

• One line of discussion asks why not use an interpreter or JIT for fast iteration; Julia and SBCL/Common Lisp are mentioned as good interactive models.
• Counterpoint: compiler speed and executable speed are not strictly opposed; many optimizations and implementation improvements can improve compile time without hurting code quality.
• For games and consoles, people note that you often must run near‑release performance even during development, making debug builds or interpreters less viable; others describe workflows mixing debug builds, partial optimization, scripting (Lua), or PC development targets.

Zig’s Positioning and Toolchain Appeal

• Several comments see Zig’s main value in its toolchain and C interop rather than the core language: easy cross‑compilation, headers/libc shipped, and use as a drop‑in C compiler.
• Zig is framed as a “modern safer C” with better defaults (bounds checks, allocator‑explicit APIs) and simpler semantics than Rust, at the cost of weaker static safety guarantees.
• Some worry that giving up Rust‑style provable safety for expressivity is a poor trade; others argue Rust is hard to master and that Zig hits a different audience and use cases.

Build Systems, Linking, and Caching

• Zig’s build.zig is Turing‑complete but optional; single files can be compiled directly, and Zig integrates wherever GCC/Clang can.
• There is Bazel support via community rules; concerns remain about determinism and caching around dynamic build scripts.
• Static linking is the default bias (e.g., Ghostty statically links Zig deps), shifting bottlenecks to linkers; incremental linkers like Wild are suggested as future improvements.
• Build caching (like ccache) is praised but also distrusted by some due to past invalidation bugs; correctness concerns can force it off, reviving raw compiler speed as a key factor.