I have had this feeling for some time as well. NixOS puts you on a power trip -- you can bring up and tear down systems in seconds; you can relentlessly experiment without repercussions; your repositories work reproducibly.

But I also learned that whether using NixOS is productive very much depends on what software ecosystems you are working in. When I was primarily doing Rust for work in Emacs, it worked marvelously.

When I switched to CLion (for various reasons), cracks started to show. CLion does not work well in combination with nix-shell, so when you switch often between projects, you end up with projects that don't build because you are not in the right environment. Currently, I am doing more Python development, and that is an absolute pain with Nix. You end up needing different sets of package versions (which are not packaged in nixpkgs) in different environments. If you need to change multiple packages in tandem, you want mutable state. The best you can do is to make a FHS environment with buildFHSUserEnv, which kind of works, but is not very smooth. At which point you realize that you are basically fighting the system.

Then there are the niches that are not well-covered. Over the past year or so, I have had to do GPU profiling more recently. Last time I tried, the usual NVIDIA tools (e.g. Nsight Systems) worked very badly on NixOS. Of course, it's a big proprietary blob with all kinds of FHS assumptions, but you need to get work done.

These are not all failings of Nix or NixOS, it is more that there are a lot of software ecosystems out there that are not really prepared (yet) for an non-FHS, immutable world.

but I’ll be damned if it’s not a preview of the future

I think for most Linux users, Fedora Silverblue is probably more of a preview of the future. It doesn't have all the features that NixOS provides, but it does have many that matter (immutable base system, atomic upgrades/rollbacks), while going further than NixOS in other departments (verified boot, SELinux, git-like store of blobs). It sticks to FHS, so a lot of existing software continues to work.

Edit: this comment is about NixOS on the desktop. I think the server is a completely different story.

This was my train of thought at the time, too. But now you're just using software normally, but with an extra step, and no NixOS benefit.

> I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it.

It's true, escape hatches exist. But they are solutions to problems you are _creating by using nixos_, which did not occur on a normal FHS system, and require time and energy investments to solve them. And those problems are landmines lurking in every piece of software you will ever adopt in the future.

> At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management.

I don't doubt this is true. But there is a cost of time and energy to get deep enough in it, and I was unable to convince myself that it was worth it during my time using the OS. I really wish that weren't the case, I love the idea of NixOS, I just can't justify learning it for a singular personal system, because it forces you to have a deep understanding of the Linux-y systems you're encapsulating, and the Nix-y layer on top.

I tried to solve many of the same problems in Arch Linux with aconfmgr. It attempts to achieve reproducibility by using a model where the state of the entire system must be represented in the configuration file, and it helps transcribe any changes back to the configuration (unlike classic configuration managers, which only manage what is declared).