I feel differently: when proponents of a thing are open about its flaws, and those flaws are not in the fundamental ideas or principles of that thing, then it makes me more convinced that perhaps the thing does have merit. (Although I can buy the argument that it's not close to "perfect", mostly because I have no idea what perfect package management would look like.)

Maybe having terrible UX is starting to look like a fundamental flaw here? I know that UX sounds like something that should be “polishable”, but at this moment I have been hearing for years about Nix being great in principle but not that great in everyday practice. (Cf. Linux on desktop…)

I'm not convinced that Nix isn't polishable. Because the language is declarative, and can be pure if using flakes, it could readily be extended with simple tooling and UI configuration that make it look and feel like other distros, with the more low level constructs still available to advanced users. It's still in a phase where most users are power enthusiasts, so polish hasn't been priority #1, but someone will come along and make a more friendly wrapper one day.

> It's still in a phase where most users are power enthusiasts, so polish hasn't been priority #1, but someone will come along and make a more friendly wrapper one day.

As a diehard Emacser, Emacs has been waiting about thirty years for someone to make it a prettier wrapper.

It's possible to be so power-user-friendly that in practice no one wants to make it end-user friendly.

In my experience UX and polish is something a project needs to start with. You don't polish after the fact, because software is never completed. Saying "we'll improve documentation eventually" often means "we will never improve documentation"

You can only work with what something is. Not with what it might be, one fine day.

Sure, but e.g. the documentation problems with Nix don't prevent you from working with it. While the problems make it less smooth and productive than it otherwise might have been, it might already be better than legacy systems for you.

In particular, Nix can be used in a non-invasive add-on manner on ordinary distributions. We have it installed on RHEL servers at work, where it is used exclusively as a build system and for "userspace programs" (not in the kernel sense, but in the sense of programs that are not core to the functioning of the system).

> Sure, but e.g. the documentation problems with Nix don't prevent you from working with it

In a world where there are thousands of things for me to learn (many of them with poor documentation), Nix is just one such thing.

The question is, do I care about its purported benefits, and sink my time and effort into it, or should I sink time and effort into learning Unreal Engine, playing Rimworld, or going for a walk?

So far, for me (and most of the world) the last three (and the rest of the thousands of things) win over Nix.

Doesn’t it say something about how useful nix is when you have all these smart people complaining about its warts (and it definitely has quite a few) but still using it?

It is the way I’ve always wanted a package manager to work, and it really does work. It feels insane to use anything else now, I can’t go back.

> Doesn’t it say something about how useful nix is when you have all these smart people complaining about its warts (and it definitely has quite a few) but still using it?

No, not really. Tech people especially are susceptible to sunk cost fallacies We also get the kick out of conquering complexity.