[tylerjl]

Scoped down to the problems that nix solves, I get the same vibes using nix as I did in the early days of docker. It solves painful problems, with a community and suite of tools large enough to be useful, and people who have paid the initial mental investment are happily using nix in lots of ways today.

But when you widen that scope to incorporate the rest of nix's warts, I'm not sure whether the project carries the requisite momentum to become a ubiquitous tool. I hope it does! The project has lofty goals and it really deserves a layer of porcelain to soften its usability and bring its benefits to more developers, because the actual, pragmatic results it delivers border on magic sometimes, and I wish more people were able to experience it. I don't blame people for avoiding that ramp-up time investement. I tried, gave up for many years, and only in the past six months or so devoted enough time to use it proficiently without training wheels. Not everyone has that luxury, nor should we in the nix community expect people to pay down enormous initial learning debt.

I began freelance consulting at the start of the year, and interesingly, more than one of my engagements turned into "let's solve this with nix", which is both surprising and encouraging. If the nix community can trim down the harsh thorns that encircle the language and tools (and provide rock solid learning materials), there's an actual chance that nix could really bloom in the near future.

[nextos]

I love Nix, I use NixOS and associated tools in many projects and I maintain several packages on NixPkgs.

IMHO Nix is relatively easy if your usecase doesn't involve unpackaged artifacts that require heavy patching to fit them into Nix.

For example, I think it's one of the best distros to run a common Linux desktop setup because you can upgrade without fear and you can test new things without adding clutter.

The biggest hurdle is documentation. Writing documentation is not as sexy as implementing new features, but that's the biggest area to improve. https://nixos.wiki has recently documented many areas that lacked sufficient coverage, but there's a ton more needed.

[microtonal]

For example, I think it's one of the best distros to run a common Linux desktop setup because you can upgrade without fear and you can test new things without adding clutter.

You can use Fedora Silverblue, which also offers atomic upgrades and rollbacks, offers support for regular RPMs as an escape hatch. It provides meaningful desktop security (verified secure boot, kernel lockdown mode, SELinux, some application sandboxing in Flatpaks). But you don't have to learn a functional language and ecosystem that is completely foreign to most people.

Oh, and Steam doesn't break all the time :).

I think Nix is great, but I wouldn't recommend most desktop users to use NixOS on the desktop, unless you are willing to invest a lot of time.

[grumbel]

> You can use Fedora Silverblue, which also offers atomic upgrades and rollbacks

The beauty of Nix with Flakes is not just upgrades and rollbacks, but that it can be completely stateless. You can just run software directly from the Git repository:

   nix run github:JUser/your_app

And if you want an old or newer version, just go:

   nix run github:JUser/your_app?rev=01f352202ad

You can even override dependencies if you like:

   nix run --override-input somlib git+file:///yourlocalfork github:JUser/your_app

There isn't a whole lot of software that has turned their Git repository into a Flake yet (i.e. added a flake.nix), so that benefit is a bit theoretical for the average user, but the potential to completely reshaping the Free Software landscape is certainly there, as Nix finally allows upstream to become a first class citizen in the distributions packaging system.

[microtonal]

There isn't a whole lot of software that has turned their Git repository into a Flake yet (i.e. added a flake.nix)

As long as the project developers are not going to use Nix themselves, there are going to be a lot of unmaintained, broken flakes. All dependencies are pinned, but the project itself may move on from what is specified in the flake. A bunch of my own projects were flakes [1], but they would regularly break, because the project would move on (e.g. requiring a newer version of libtorch), but I forgot to update flake.nix/lock.

Of course, you can still run historical versions, but when the main path doesn't work, many users will just move on. So, including Nix flake files becomes more of a liability to a project than an asset.

(Besides that, it probably fills your store with many, potentially vulnerable versions of glibc and whatnot due to use of many different nixpkgs revisions, a problem that the centralized nixpkgs package set doesn't have.)

[1] I even implemented/contributed the cargoLock functionality, so that you can use buildRustPackage (rather than an external solution) without needing to specify the Cargo vendoring hash to make it easier to use buildRustPackage in your own repositories:

https://nixos.org/manual/nixpkgs/stable/#importing-a-cargo.l...

[Bolkan]

> because the actual, pragmatic results it delivers border on magic sometimes

I was able to run 10 years old chrome builds on latest nixos using nix. Windows users might read this and go meh but linux people know how big of a deal that is.