[peterbecich]

i.i.r.c. the answer to this question is the complexity of Nix is necessary to achieve the level of assurance it provides.

" You may quickly encounter Nix language expressions that look very complicated. As with any programming language, the required amount of Nix language code closely matches the complexity of the problem it is supposed to solve, and reflects how well the problem – and its solution – is understood. Building software is a complex undertaking, and Nix both exposes and allows managing this complexity with the Nix language. " https://nix.dev/tutorials/nix-language.html

My read of this is any other build system has random elements that are usually fine but sometimes cause issues. There are no random elements in a Nix expression.

i.e. Yarn has a lockfile, but does not guarantee the system underlying the Yarn process is "locked." Nix does this down to the fundamental Linux/Mac libraries.

The upside is this complex configuration is a one-time cost for your project. Using a project configured with Nix can be simple. For instance, a Nix Flake can be set up for your project which defines your project workflow commands in the shell. These commands are completely portable.

Nix is not a virtual machine. But it does guarantee the command will run the same way on equivalent systems (unless it does something that goes outside the Nix boundary).