I used Nix and NixOS for more than a year as my daily driver. I've contributed to Nixpkgs. I agree with the author on most if not all of their points. Here's some advice: If you're interested in Nix, take steps not leaps. Use the Nix package manager. It's a great addition to distros like Debian. Then maybe use Home Manager (even though I think Home Manager is way over-hyped, see below). Then write a bunch of derivations. Then go learn the ins and outs of systemd. THEN go play with NixOS. If you skip any steps before the NixOS part, you will get lost in the weeds. The happy path of NixOS is very happy. The other paths are very challenging. You should really know a lot about both Nix and more traditional Linux packaging methods before you go all in on NixOS. And honestly, learning more traditional Linux utilities is a far better use of your time than learning the complex, ever-changing Nix landscape. It's a super cool project, I'm so glad it exists. But it should really be viewed as a _research_ project. Many good things will come out of it. Hopefully one of those things (like the author mentions) is a Nix clone written in a common language with a much better UX. Until then, try to avoid the urge to play with shiny things and stick to just using the Nix package manager and more traditional tooling.
And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it. It actually just makes everything 10x harder. The Home Manager Nix abstractions are terrible but people seem to love it? Why would I write my i3 config in Nix?? An i3 config literally cannot get any simpler. Why make it more complicated for no benefit? I also don't need a declarative list of all installed packages. I'd rather just use `nix-env` personally.
> And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it
I don't really agree, I spent about 30mins to get my home-manager config to support an m1 mac [0]. I don't really want to think how long it would take me to look up all of the homebrew package names, and learn a new package manager. Instead, I just pushed all of the linux-specific items into their own bin, a little more logic, and I was able to get back to a comfortable terminal + git + vim settings.
Also, nix exposes congruent configuration management[1]. The state of my system is an exact reflection of the configuration. With other tools like ansible, vagrant, etc, I would get reconciliation configuration which is close on initial install but configuration drift is an ever-present concern; not to mention that large recipes and playbooks can take a very long time to run. Going the homebrew route would be divergent configuration, it would be very hard for me to get back to a certain configuration. With nix (and by extension home-manager), I can version control the configuration, improve it, roll it back, w/e I want.
> Why would I write my i3 config in Nix??
You do get some type checking, although the iteration time would probably be similar. You could also just do `xsession.windowManager.i3.extraConfig = builtins.readFile ./i3.config;` if you really just wanted to wholesale read in your existing profile.
> I'd rather just use `nix-env` personally.
nix-env is a double edge sword. You can rollback (somewhat, I believe it's just a stack of all changes), which is an improvement. However, nix only retains the "derivation name" to try and management. But for packages like python38, if you try to upgrade it, it will determine that `python-3.11-a3` is the package which is the most up-to-date. I try to discourage using nix-env.
WRT Home Manager, that makes sense and portability is definitely a cool benefit of Home Manager. But keeping all of your config for multiple workstations in one has drawbacks too. I found myself frustrated when I wanted to install something but I forgot to push changes from another computer so I needed to stash or rebase later on. Just to install a package! I only have one workstation and a small amount of servers, and I tried running NixOS on everything. It worked well (I still have multiple servers running NixOS actually) but for me, the benefits just weren't worth the overhead of living full time in Nix land. Now I use Debian stable for new servers and I prefer it. But yeah, lots of personal preference here. And WRT nix-env, it seems troubling to me that the fundamental tool of the Nix CLI is something that you recommend people stay away from. I think you may have be right about that recommendation, but I think it shows that Nix as a product is far off from being a "pick up and run" tool for average developers. I really hope that it will somehow get to that point but, like the author says, I don't think it will be Nix itself because it has burrowed itself into a bespoke, complicated UX that has a huge learning curve. I like simple things with elegant UX so that's where I'm coming from. There's just so many ways to use Nix, like, TOO many ways. But I'm glad that they're pioneering this space.
And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it. It actually just makes everything 10x harder. The Home Manager Nix abstractions are terrible but people seem to love it? Why would I write my i3 config in Nix?? An i3 config literally cannot get any simpler. Why make it more complicated for no benefit? I also don't need a declarative list of all installed packages. I'd rather just use `nix-env` personally.