I have been using Nix regularly since roughly 2019, when I set up my primary build server to use Nix to manage the various toolchains, though it wasn't until 2022 that I really invested heavily, and I'm now using Nix in combination with other more traditional DevOps tools to provision and manage more than 10 physical machines and 50 VMs in my homelab.
And here's why I will most likely never move away:
This is meant as a "response" to Carlos' Moving away from Nix, not as a rebuttal, but as a telling of why Nix works for me. I will go over the same points as Carlos' post, but from my perspective of having embraced Nix, rather than "dealing with it," and why they don't bother me.
And I wouldn't have it any other way. The fact that everything from the specifications of my VMs to the services that are running on them, to the api keys, securely managed with sops-nix, to whatever you can name, is all declared in a single repo (And before you ask: the repo isn't public and likely never will be. I have previously tried to move some stuff to a public repo, but it's at this point too much work, for no benefit for me.), and it makes it incredibly easy whenever something isn't working as expected to narrow down where it's coming from. No scouring around default configuration files the distro ships alongside the package in some path in /etc/, no forgetting that you turned on some logging setting while you were testing something.
I use Nix on my MacBook, and recognize that it takes a bit more elbow grease to fit it into the ecosystem, but I have found that this usually pushes me to better solutions in the end, some of these include
I think I am less bothered by "outdated"/not always the latest packages than the average Linux/Neovim/Terminal user, before Nix most of my Linux systems were Debian Stable, or Ubuntu LTS, I have never really cared for the bleeding edge, at most I have enjoyed being able to pull in the newest version of a few select packages, and even then I felt annoyed when on Arch I was still at the mercy of the packagers to package up the latest version of LLVM or similar. Nix really shines here, I can run 99% of the packages on my system from the stable branch of nixpkgs, and the few packages I care about I can pull from unstable or even master, and this worked great for me for a long time. I have since transitioned to vendoring all the direct packages I use on my system, and only having the dependencies rely on nixpkgs, I think this is probably the nicest balance of control vs not needing to keep up with every single transitive dependency your system has.
I really have nothing to say here, Nix is slow, and I wish it was faster, my philosophy here though is also why I like Rust, the compile/rebuild speed is just not that important to me compared to the correctness/reliability of the end product. This likely also comes down to the fact that I hate configuring software, and this probably also comes as a shock to most people who see how deep in Nix I am, but I just don't care for spending hours tweaking something to be exactly right, and it is a large reason as to why I am such an advocate of good defaults.
With that said, I do still have scripts that help to mitigate this somewhat for the programs I do configure, either because the defaults are simply too bad and the alternatives are worse, or because I use it too much to ignore the speed gains from optimizing my use of it. One such script is eedit.sh which lets me quickly prototype changes to a nix-managed config file, and properly revert to the "correct" version when I'm done. This means I spend less time rebuilding for the sake of testing out if I typed out the correct incantation to make neovim/emacs behave as I want.
And neither is it to me! I have read all the Is NixOS truly reproducible? and similar articles, and well, frankly... I just don't care. Nix is reproducible enough, and even if it wasn't, it is probably the least important reason as to why I use Nix. Nix for me is a way to centrally manage everything from network configuration, to package build recipes, to server infrastructure, without needing to context switch between terraform, rpm/deb recipes, random python and bash scripts. I know all of it at the layer that matters to me is just Nix.
I rarely upgrade my client machines (macbook, desktop, other laptops), and generally prefer to work connected to a remote VM.
So, I'll gladly concede the point: my desktop configuration probably wouldn't "just work" if I tried to restore it on a new machine two years from now. And for me, that's fine. I use Nix for my client devices because I am now familiar with Nix and it integrates nicely into the rest of my configuration, but for me it's secondary. The reproducibility that I actually care about is in the form of having my set of tools available when I spin up a VM with Nix, so I don't mind having to "fiddle around" with my configuration when I get a new machine, because I would have to without Nix anyway.
This ties somewhat into the same point as before for me. I rarely do any serious work on my local machine, so I have no problem having a MacBook with 8GB of RAM and 128GB of storage, because all my important files are either photos in iCloud and/or on my own servers, or my work/projects, where all the files again are on my VMs. So I don't really mind that 50% of my local disk is taken up by Nix, and for my VMs I build all the packages that are needed on a central server and so the nix store is only populated by runtime dependencies of the services that are running.
This is the point I sympathize with the most, and I have no good answer to this. Though the core issue is very different for me and Carlos here. I have no problems dealing with the nixpkgs repo, but rather that the culture around how to contribute to nixpkgs, is just not for me, I don't agree with the force-push, only 1 commit per PR stance, and I am not excited to work with a lot of the vocal userbase of Nix.
Nix isn't simple, and it doesn't have to be. Nix is truly an excellent piece of tooling, and I don't think I would be as excited to run my homelab as I am without it.
I think Nix and Home Manager for desktop use are still too much friction for most people who don't want to care about it to the same extent that the majority of the community wants to. Nix is a power-users dream, and it shows in pretty much every facet of interacting with Nix, from nixpkgs, to the community, and to the day-to-day use of it, but I could not imagine managing an HPC environment/multi-user linux system without Nix, the alternatives here after being used to Nix feel stuck in the past like, frankly, nothing else.
But Nix is not for most people, and it shouldn't be, and as much as I'd like for everything I interact with to just work with Nix, with Nix's complexity and poor documentation, this isn't a reasonable ask of most developers.