I've been using it for 9 months on laptop. I really love the idea. But had to ditch it and use ubuntu instead, because it routinely turned a 3-minutes-long-operation into 6 hours. I had to do work, not mess with configuration and read 6 A4 pages worth of text only to install some python package.
I strongly feel like it needs to take the idea to a new level, ditch the messy language and completely refactor it. Don't get me wrong, NixOS is 17 years old and it still feels like alpha version.
Wait until you try to write your own package definitions. It’s a completely uphill battle, not least of all because nixpkgs is incredibly difficult to parse as a reference (no static types so good luck guessing what any given function takes for arguments, precious little documentation, no decipherable code organization, few if any direct imports to help you find dependency definitions, etc).
It's not so bad actually. To add a new package there's only two files you have to touch, add a new default.nix somewhere in the pkgs/ tree and add your package to pkgs/top-level/all-packages.nix. Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write.
This comment reminds me of the "How to draw an owl" meme:
1. Draw some ovals
2. Draw the rest of the effing owl
Yes, you only have to write your Nix expression code in a couple of files; of course, the issue is "how to write that Nix expression code correctly".
> Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write.
This is exactly the fallacy I addressed in my comment--Nixpkgs is a really brutal reference for a variety of reasons. Let's say you're building a Python project--first of all, good luck finding a good reference package in nixpkgs if you don't already know where the Python packages are. Secondly, the general scheme seems to be "import nothing, write some function that takes dependencies as arguments", which means you'll have no import statements pointing you to the source files for the dependencies. Further, because nixpkgs doesn't believe in docstrings or static types, you'll have nothing that helps you infer the shape of the thing you're searching for or otherwise provide you with reliable grep criteria. You'll need to grep for the call site for your function to determine what gets passed in, and that thing might be the result of calling some other function with its own args, so you end up recursing through this process for the whole dependency tree. It's needlessly tedious, and this example is just the tip of the painful iceberg.
[0] https://github.com/lf-/nix-doc