It also comes (practically) shackled to nixpkgs which is a barely-documented cataclysm of packages that extensively bake in assumptions that you are also going to use Nix as your runtime environment.
The principles behind Nix are nice but the implementation is sorely lacking in my experience.
This is sadly true, I've tried setting up a bazel-esque C++ build system in Nix, and the requirement for 1 derivation per .o file makes it very inefficient
> It also comes (practically) shackled to nixpkgs
This isn't true, and I think it is a shame that it seems true. Nixpkgs is both awful, and completely optional. It would be great if there were more resources on how to use Nix without Nixpkgs, or as is commonly requested, a smaller, cleaner and better engineered alternative
I feel like a core problem though is the assumption you use Nix for everything - as soon as you try and pull in prebuilt pieces for pragmatic reasons, or output something you can use somewhere outside of nix, it starts making life hard.