Zb: An Early-Stage Build System

Overall reaction

  • Many commenters are excited about zb as a Nix-inspired, Lua-based, early-stage build system, especially for its design goals and Windows support.
  • Some see it as “Nix-like but friendlier,” while others say they don’t yet see enough benefit over Nix to justify switching.

Language choice: Lua vs alternatives

  • Several like Lua as a DSL: simple, embeddable, and expressive; some mention editor tooling and typed Lua variants as mitigations for lack of static typing.
  • Others argue a declarative or statically typed language (Starlark, Scala-like, custom DSL) might better fit reproducible builds and reduce configuration pain.
  • There is concern that a general-purpose, mutable language with top‑level variables can easily compromise hermeticity if not carefully sandboxed.

Nix, Bazel, Buck2 and theoretical grounding

  • Lots of comparison to Nix: content-addressed store, sandboxes, non-determinism handling, live-bootstrap, and the heavy social/maintenance cost of wrapping arbitrary upstream build systems.
  • Discussion of Bazel/Buck2: static vs dynamic build graphs, sandboxing, Starlark, genrules, and remote execution. Some want better Bazel–Nix–zb interoperability.
  • The “Build Systems à la Carte” paper is referenced to frame dynamic dependencies and scheduler strategies (topological, restarting, suspending).

Sandboxing, nondeterminism, and hermeticity

  • Commenters strongly stress sandboxing as non-optional; zb has Linux sandboxing prototyped and Windows sandboxing planned.
  • zb’s explicit support for non-deterministic builds is seen by some as a valuable “escape hatch” that reduces friction when migrating existing workflows, but others worry it conflicts with strict reproducibility ideals.

Windows support and bootstrapping

  • Windows support is a big selling point compared to Nix; people discuss MinGW, Visual C++–based bootstraps, and desire for a pure, Guix/ live-bootstrap–style story where possible.
  • There is interest in using zb as a cross-platform package/build layer similar to Nix but with less friction.

UX, terminology, and ecosystem

  • Multiple commenters criticize Nix’s terminology (“derivation”, “flakes”) and documentation as confusing; some suggest friendlier terms like “build plan” or “recipe.”
  • Others defend keeping established terms for compatibility.
  • Monorepo-based ecosystems (like Nixpkgs, Buck-style repos) are highlighted as crucial to long-term success; several urge zb not to rely on a fragmented package landscape.