The inconsistent CLI is definitely a problem but I don’t think it’s the biggest issue.
The biggest issue is that it’s hard for people to read the nix code and understand what is going on. It took me a looong time to be able to do simple things. Now that I know how to code nix it’s great but it wasn’t easy at the start. Not as easy as writing a Dockerfile for example.
Another observation is that most of the time I am forced to open the nix code to figure out what it’s doing. In other languages I can look at the auto-generated library dock and just look at the interfaces, this isn’t the case with Nix because there is no auto-generated doc for Nix code.
The language itself also reports a lot of hard-to-understand exceptions. It took me a long time to figure out how to debug errors like
error: value is an integer while a set was expected and it’s still not great. I really would prefer something like:
variable X at position 3:4 is an integer while a set was expected with a nice squiggly underline of the code.
There is also a lot of magic happening in the default builder which makes things easy but hard to understand when it breaks. For example adding
cmake to the build inputs creates some magical new steps.
In general there are quite a few concepts and paper cuts to understand. What is a channel, why can’t I list the channel when it’s clearly finding one. Why do I have to use
nix-build to build my package but
nixos-rebuild to rebuild my system configuration. What are profiles. What are GC roots. Why do I still have the entries in grub after garbage-collection. Why can’t I manage my user dependencies decoratively.
I think these issues are hard to solve because usually contributors are mainly interested in solving their specific problems, which is completely fine to be clear, but doesn’t help address those bigger issues.