Type resolution redesign, with language changes to taste

Original Article ↗ Hacker News Discussion ↗

Production use and ecosystem stability

  • Several users run Zig in production (e.g., databases, compilers, terminals, CLIs).
  • Reported upgrade pattern: pin to a release (0.14/0.15), then batch-refactor once or twice a year.
  • Core language is seen as relatively stable recently; most churn is in the standard library and build system.
  • Third-party packages are fragile across versions; many larger projects avoid them or fork/pin dependencies.
  • Some learners find it frustrating that tutorials target 0.15 while they’re trying 0.16/master, where std APIs have shifted.

Tooling, build cache, and incremental compilation

  • Large .zig-cache directories (100+ GB) are common for big projects; cleanup is mostly manual today.
  • Incremental builds exist but are unreliable for some setups; many see full rebuilds of ~20s+ as normal.
  • Environment variables or tmpfs are used to centralize/periodically nuke caches.

Type resolution redesign & breaking changes

  • The 30k-line type resolution rewrite is viewed as scary but appropriate for pre‑1.0.
  • It converts type resolution into a DAG, fixes many long-standing bugs, and improves incremental compilation.
  • Authors stress that the user-visible breakage is minor (e.g., small std API adjustments, a few comptime annotations), not a mass rewrite.

Governance and philosophy on breaking changes

  • Zig is explicitly BDFN-governed; there’s no formal spec yet, and full transparency isn’t a primary goal.
  • One camp sees aggressive breaking changes as healthy cleanup before 1.0, even if it takes many more years.
  • Another camp criticizes the culture around breakage, saying deprecation paths are weak and upgrade work is pushed onto users.
  • Concern is raised that after ~10 years the language still causes regular breaking changes, with 1.0 seen as distant.

Comparisons with other languages

  • Rust: praised for long-term backward compatibility and “closed world” traits; seen as more complex but with stronger safety guarantees.
  • Zig: described as “modern C” emphasizing simplicity, explicitness, zero-cost abstractions, and powerful compile-time metaprogramming.
  • Odin/C3/D: cited as alternatives with more stable specs and faster compile times; one commenter claims Odin yields more shipped games per user.
  • Go: compared as another “modern C” but with GC, making it unsuitable for some real-time/embedded contexts.

Generics, typing model, and ergonomics

  • anytype and structural/“duck-typed at compile time” generics are powerful but harder for tooling, docs, and IDEs.
  • Some users want trait/interface-like constraints; others are skeptical this will be added.
  • Discussion around the “zero/empty type” (noreturn / uninhabited type) notes that the redesign moves Zig closer to formal type-theoretic semantics.

Build system and namespaces

  • build.zig is praised for power but criticized as a high barrier to entry and opaque to IDEs.
  • Zig’s “types as namespaces” design (imports become structs with fields) is seen by some as elegant minimalism rather than a missing namespace feature.

Windows APIs and RNG

  • The devlog’s move from higher-level Windows APIs (kernel32/advapi32) to lower-level ones (ntdll) sparks interest; parallels are drawn with errno-style designs.
  • A correction notes that modern Windows RNG (ProcessPrng) is guaranteed not to fail and that some cited usage patterns are outdated.