> Nix is very awkward (and slow) to use for fine-grained caching, which is price of entry for a decent build system.
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
Honestly, I'm hoping for someone to use AI to translate the Nix universe of scripts to a saner and more modern, user-friendly language.
I know it technically isn't true and I use the word 'practically' deliberately. The problem is that as soon as you opt into one part of nixpkgs (say a compiler) you end up implicitly opting into large parts of it because of common code in nixpkgs that make assumptions about undocumented magic environment variables etc that other packages (e.g. libc) may make use of or set.
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.