It very much doesn't work like that. I work on Guix a little, and I remember someone saying ~5% of packages were broken at any given time. there is something of an equilibrium between packages breaking due to changes and someone fixing them. Packages are also not truly functional in the functional programming sense. For practical reasons, Nix/Guix just try their best to remove as much state as possible to make things behave consistently. But for example, the number of cores available is different between different machines and race conditions can occur.

Builds break over time[0]. Generally this is from big updates like gcc, glibc, llvm, openssl, etc.

Most software which is maintained upstream and within nixpkgs is fine. But there's a bunch of "cruft" that you accumulate over time.

[0]: https://hydra.nixos.org/jobset/nixpkgs/trunk

P.S. The link above builds for x86_64-linux, aarch64-linux, aarch64-darwin, x86_64-darwin, which also contributes to the failure rate.

This was my first thought as well. Their tool for managing builds (Hydra [1]) was pretty simple to set up last time I tried.

In practice a few percent of packages will fail to build (packaging is hard!) but it’d be good enough for getting large quantities of compiled code.

[1] https://nixos.wiki/wiki/Hydra