Type resolution redesign, with language changes to taste

Original Article ↗ Hacker News Discussion ↗

A major redesign of Zig’s type resolution system—implemented as a 30,000‑line compiler change—is being framed as necessary pre‑1.0 surgery to formalize core semantics, improve incremental compilation, and eliminate long‑standing bugs, with maintainers saying the actual breakage for users is minor. Commenters weigh this against ongoing concerns about Zig’s rapid evolution: frequent standard library changes, fragile third‑party packages, large build caches, and the expectation that users absorb most upgrade work. The thread contrasts Zig’s “break often to get it right” culture with languages that prioritize long‑term stability, and situates Zig alongside Rust, Odin, and others in terms of safety guarantees, tooling, and suitability for production use.

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.