I agree, as a new user I think Nix(os/pkgs)'s deficiencies are:
1. Documentation doesn't really explain how NixPkgs works and thus there is a lot of magic that is unintuitive for a new user.
2. The Nix language has a number of annoying gotchas. I always go through several rounds of syntax errors before several rounds of name errors before code can run.
3. Whence this definition? NixPkgs' extreme inversion of control approach makes it hard to guess by looking at code, and I haven't found how to set up good tooling.
4. Clickability. Sometimes you just want an official way to turn things on and off or choose defaults and there is no officially-supported GUI helper. This makes it hard to expect that people will start to use Nix who aren't basically functional programmers already. I don't think I could convince people to use it.
5. Efficiency. Long-ish build times for simple changes, too much memory use to run nixos-rebuild on a small computer.
I think you touched on it with #3, but here is my biggest issue with Nix:
nixpkgs
It's a monolithic source tree full of disorganized interdependent "derivations". It's nigh-impossible to find your bearings, and that's before you even think about the bazillion git branches and GitHub PRs.
The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. I came to NixOS hoping for a package manager; but what I got is something else entirely. I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other.
The nix language isn't the problem. The problem is the impenetrable novel that was written in it.
I think it's reasonable to say that the nixpkgs codebase is a behemoth that can be quite difficult to understand.
I think "nix and multiple versions of a package" is more nuanced. In that thread, several of the replies are saying "just use ...". As in, it's possible to vary the version of a package built. But, nixpkgs itself only has multiple versions of some package when that package is very popular (e.g. python, nodejs).
> The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. ... I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other.
Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository.
Taking one large codebase and splitting it up into many codebases doesn't necessarily simplify things overall.
> Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository.
No, but it does define how (and where) I will write that code.
It's not uncommon for a package to need complex dependencies like udev. It's definitely necessary for nixpkgs to have opinionated decisions about how dependencies are structured, and what options/defaults are available and where. The problem isn't the quality of nixpkgs, or with any of its design decisions. The problem is that those design decisions are centralized and interdependent. That's the core issue that lead nixpkgs to be so poorly documented. It's the core issue that makes it incredibly challenging to create a sensible UI/UX for Nix and NixOS.
There are definitely benefits to a monolithic source tree. You can guarantee compatibility. You can have a clear place for communication about breaking changes and security updates. The thing is: you can get all of this without a monolithic source tree. Debian has been doing it for 30 years now. If anything, Nix should be able to do it better!
If the goal is to have a diverse set of package repositories, what better way to deliver them than a purely-functional declarative package manager? Nix is the one package manager that can handle totally incompatible packages, breaking changes, etc. all without breaking a sweat; yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present. I see it as a missed opportunity.
> No, but it does define how (and where) I will write that code.
I don't follow your rationale here.
e.g. many people write packages for their own "nix user repository". https://github.com/nix-community/NUR or there are examples of fairly sophisticated programs which declare packages outside of nixpkgs, such as helix or llamacpp.
> yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present
In a programming language, a function can be called with different arguments.
With Nix, since the packages are the result of functions, you can use these package definitions with whatever incompatibilities you like. -- I'm not sure what use case you're thinking of that Nix can't handle.
Nix can handle it, but can the user? That's my question. It took a while for me to understand the basic organization of nixpkgs well enough to do things like reconfigure a package properly for another package. Documentation-wise, the big picture isn't well-explained and, like I said, there is no official documentation recommending the use of a GUI tool to help. I see that there are tools available, but very little uptake of them in terms of documentation.
I am not sophisticated enough in Nix to say what a good roadmap would be. But I feel that if I were sophisticated enough I would be trapped in the mindset and not able to see how it could be made easier to comprehend for new users and tools. But who knows? As of now it's a very interesting puzzle and, while I take a lot longer to accomplish what I can do elsewhere, I enjoy the little aha moments along the way.
In this recent post discussing efforts which have been made to improve documentation, the author reckons that one of the reasons Nixpkgs is difficult to understand is that Nix's powerful expressiveness allowed different people to take different approaches to solve similar problems. (As opposed to, having to rely on a common solution).
IMO.. difficulties with Nix fall into three broad categories: with Nix's idiosyncrasies, with the Nixpkgs codebase, or with the software you're trying to get Nix to run.
On most OSs, you might not need to have a deep understanding of what's going on in order to fix a problem. With Nix (& NixOS), running into problems probably requires a decent grasp of what you're doing, as well as what Nix is doing, and maybe how the Nixpkgs code is doing it.
> the use of a GUI tool to help
I think between "easy/hard to understand" and "easy/hard to model with a GUI", GUI helps a lot with things that are easy, but not so much with things that are difficult.
e.g. with VSCode, you can get a GUI to help you set options. Emacs also has a GUI to help you customize options; but you don't get a GUI that helps you write elisp.
1. Documentation doesn't really explain how NixPkgs works and thus there is a lot of magic that is unintuitive for a new user.
2. The Nix language has a number of annoying gotchas. I always go through several rounds of syntax errors before several rounds of name errors before code can run.
3. Whence this definition? NixPkgs' extreme inversion of control approach makes it hard to guess by looking at code, and I haven't found how to set up good tooling.
4. Clickability. Sometimes you just want an official way to turn things on and off or choose defaults and there is no officially-supported GUI helper. This makes it hard to expect that people will start to use Nix who aren't basically functional programmers already. I don't think I could convince people to use it.
5. Efficiency. Long-ish build times for simple changes, too much memory use to run nixos-rebuild on a small computer.