Self-hosted x86 back end is now default in debug mode

Original Article ↗ Hacker News Discussion ↗

Debug backend, binary size, and debuggability

  • New self‑hosted x86_64 backend is used only for -ODebug; release modes still use LLVM.
  • Debug binaries are huge (e.g. “hello world” ~9.3 MB) but mostly due to debug info; stripping shrinks them dramatically.
  • Users compare -ODebug vs -DReleaseSmall sizes and ask if self‑hosted backends will ever match LLVM’s size/quality in release; answer: it’s a long‑term, not near‑term, goal.
  • Zig‑aware LLDB fork plus the new backend is reported to significantly improve the debugging experience.

Compile times, bootstrap, and build workflow

  • Self‑hosting backend plus threading cuts Zig self‑compile from ~75s to ~20s, with a branch at ~15s; a minimal subset builds in ~9s.
  • Significant time is attributed to stdlib features brought in by the package manager (HTTP, TLS, compression) and comptime‑heavy formatting.
  • Comparisons with D, Go, Turbo Pascal, tinycc, and C++ modules: some see Zig as rediscovering “fast compilers” while others note ecosystem/tooling complexity.
  • For contributors, advised workflow is to download a prebuilt Zig and run zig build -Dno-lib (optionally with -Ddev=...) instead of full bootstrap, which is slow due to WASM→C translation plus LLVM.

Comptime performance and metaprogramming

  • comptime is widely praised but also criticized as slow (reports of JSON parsing at compile time being 20x slower than Python).
  • Core devs say improving comptime means large semantic-analysis refactors; it’s planned but competing with other priorities.
  • Heavy use of std.fmt and comptime formatting currently dominates some compile-time cost; typical projects that use comptime “like a spice” are less affected.
  • Some argue pushing work to compile time is worth it; others recommend moving large tasks (e.g. big JSON) into build.zig instead.

Backends, Legalize pass, and non-LLVM ambitions

  • AIR is a high‑level IR; backends lower AIR → MIR → machine code.
  • The new Legalize pass rewrites unsupported high‑level AIR ops into simpler sequences a backend can handle (e.g. wide integer emulation), making new backends easier at the cost of some optimality.
  • This is expected to accelerate an upcoming AArch64 backend.
  • There’s philosophical support for non‑LLVM backends to improve iteration time and reduce dependence, but also recognition that LLVM enabled many modern languages and consoles.

Async/await, hot reloading, and game dev

  • Many are excited about hot code swapping and see it as a big win for game development; others note similar capabilities in MSVC/Live++ or C# hot reload.
  • Some devs already use Zig in shipped games; others still prefer C#/Rust for better existing hot‑reload and async ecosystems.
  • Async/await was removed; plan discussed is to reintroduce stackless coroutines as lower‑level primitives powering std.Io, giving flexibility between stackless/stackful designs.
  • Timeline is explicitly uncertain; some insist robust async is critical pre‑1.0, others want Zig to stay closer to C and process/threads.

Safety, segfaults, and language comparisons

  • A user is alarmed by many GitHub issues mentioning “segfault”; others argue sheer issue count is a poor maturity metric and common to all large compilers.
  • Consensus: Zig is not memory‑safe by design; it aims to make unsafe operations explicit and simple, not to prevent them, so user code can absolutely segfault.
  • Debate veers into C’s “legacy cruft,” memory‑safety history, hardware tagging, and formal methods; some argue C can be written safely with abstractions, others say practice and incentives suggest otherwise.
  • Compared to C, Zig is praised for: explicit optionals and errors, tagged unions/enums with exhaustive switches, slices with lengths, defer/errdefer, integrated build system, allocator‑driven APIs, and straightforward C interop.

Ecosystem, funding, and readiness

  • Zig’s foundation is said to spend most revenue directly paying contributors; compared favorably to some other foundations.
  • No concrete 1.0 date; many important tasks (incremental compilation, backends, async, comptime speed) compete for attention.
  • Recommendation from commenters: pin a stable Zig release for serious projects rather than track nightly, and treat Zig as evolving but not yet “finished.”