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.