Not OP but you don’t have to look far when it comes to Nix. Here’s a couple of the more annoying ones:
Example 1:
updating dependencies that are outside of nixpkgs is not a one command ordeal. Especially if you’re doing something like updating the commit shape of a packaged release you’re targeting. I think there’s no reason they couldn’t have some clean way of writing rules automate update non-nixpkgs (why do I have to do this dumb nix-prefetch-url thing myself to compute some hash?).
If I am selling nix to end users as a system package management solution I’m comparing it to tools like brew. As long as you stay in nixpkgs it’s fine - but as soon as you’re out of that (which almost everyone is going to have at least o e package that is either not in nixpkgs or they can’t use the nixpkgs one for some reason) maintenance is no longer as simple as brew update / nix flake update.
Example 2:
Nix just doesn’t have very good debugging tools. It reminds me a lot of terraform. Yes there is an REPL but the simple task of breakpointing and seeing the value of data structures is not really straightforward in nix. If you want to it language to be approachable you need to make it dead simple to immediately be able to spit out its state in a way that an engineer knows how to work with it. I would not say the process of doing so in Nix is dead simple
Use it as a signal to start an investigation into how many agree with that sentiment, try to measure the resulting adoption dropoff, and use those stats to push for a UX redesign.
This is a pretty ignorant stance. It implies that the issues would somehow be easy to address if they were just acknowledged. Are you aware of the efforts that have been put into this so far? Have you considered that achieving the vague improvements you are asking for, working on a groundbreaking technology while holding together a rapidly growing community, is just really hard?
