Zig: All Package Management Functionality Moved from Compiler to Build System

Zig’s development ethos and role of LLMs

• Several commenters see Zig as evidence that “software as a craft” is alive, valuing deliberate human design over LLM‑generated languages.
• LLMs are viewed as great for small DSLs or localized tasks, but not for core language/compiler code intended to last decades.
• Concerns: LLM‑written code is verbose, intention is unclear, and reviewing it for critical systems is hard.
• Others report heavy, successful use of LLMs in business codebases, especially with explicit, defensive, low‑abstraction styles that make AI‑generated code easier to review.

Build system, WebAssembly, and sandboxing

• There’s excitement about the plan to move Zig’s build system into a WebAssembly VM to sandbox build.zig.
• Pro‑sandbox:
  • Limits what untrusted build scripts can do, especially when editors/LSPs run them automatically.
  • Enables fine‑grained privilege brokering and easier auditing of which dependencies need extra capabilities.
• Skepticism:
  • If build scripts can still spawn arbitrary processes (e.g., cmake), sandboxing is partly “security theater.”
  • Some argue whole‑environment/container sandboxing (bwrap, devcontainers, isolated servers) is more appropriate.
• Counterpoint: security isn’t all‑or‑nothing; partial sandboxing still raises the bar and improves reproducibility.

Package management and polyglot build concerns

• Some lament every language inventing its own package/build system; they’d prefer a good, polyglot, cross‑platform system.
• Buck and Bazel are cited as closest to that ideal but seen as burdened by their origins.
• Debate over whether a build system should also be a compiler frontend vs. just orchestrate multiple independent toolchains.

C/C++ package management and dependency culture

• Mixed views on the lack of a standard C++ package manager:
  • Pro: forces careful dependency selection and manual updates, avoiding “cargo‑style” trees with hundreds of transitive crates.
  • Con: leads to every large C++ project re‑implementing basic components (JSON, async, etc.), often poorly.
• Conan and vcpkg are mentioned as de facto solutions, but not universally accepted.

Design mistakes, evolution, and Zig’s package move

• The “radiator fluid in the fuel tank” analogy is used to criticize languages that later undo early design choices (e.g., moving package management out of the compiler).
• Defenders say early tight coupling is a pragmatic way to ship and iterate; decoupling before 1.0 is seen as responsible evolution.
• Some worry modern languages ignore historical lessons; others stress that language design is inherently iterative and extremely hard.

User-facing impact (e.g., @cImport)

• One commenter connects the package/build changes to the earlier removal of @cImport, seeing it as a UX loss, though others clarify the motivations are separate (LLVM/libclang decoupling vs. package management refactor).