> The problem is when you have to come off the happy path in nixos and now you're debugging some interestingly written c++ code that evaluates a language that has a derivation expressing what you wanted done.

I agree that Nix or NixOS are risky tools.

But it's not a problem that the `nix` program is written in C++.

A lot of the friction comes from the tension between NixOS's idiosyncratic design & its constraints, against the often 'dirty' way software is practically written.

For example, roughly, Nix's ideal software follows `./configure && make && make install`, where nix can then symlink the dependencies & maintain these in a read-only store. -- Whereas, say, Python wheels break this (because the precompiled binaries assume shared libraries are available globally).

When you run into friction with NixOS, you may need to understand things with a depth and breadth which aren't required with more common Linux distributions. (Including e.g. maybe needing to understand the rather large and obscure nixpkgs).