> When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity

I think this is where most of the "i went back" posts I read came from. That and hitting issues with programs that expect to be able to write to some XDG dirs.

> When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity as you now need to fully understand the nix language and its concepts like derivations. This isn't necessarily hard but it is not documented well at all, and there are factions in nix at odds with each other (flakes vs. nix-env) which make learning it even more confusing.

Exactly this was why I am so hesitant to switch to nix. I tried to dig into the details of nix, language, derivation and whatnot, but documentations and community discussions are, in my experience pretty segregated that left me confused, and I eventually went back to arch.

In 90% of the cases it is as easy as modifying the earlier version’s version and hash. I think learning nix from outside-in is perhaps easier - grep for something you are looking for, and as if it were a language and you are a small kid, imitate that.

Though I will give you that there is enough complexity in specifying which nixpkgs/flake gets built, where is it places, etc as is, especially with the `nix-\w+` vs `nix \w+` variants being slightly different, to the point that I always have to look it up in the man page/in my history whether I need -A and the like.

Sorry to be blunt but I've seen nearly exact comments as yours and they come off as someone who hasn't really used Nix and doesn't understand the value proposition and the problems it solves.

I've used Ansible for years, then moved to Nix and have been on it for a year and a half. Yes the configuration language is more complex than Ansible's but it's also way more consistent and predictable. The bit of complexity comes with a lot of additional benefit. Ansible half-asses it, only giving you idempotency if you stay within certain boundaries in how you write configs. And a leaky system is a system that will break. Making it even worse is that you are building on top of a moving target with a distribution underneath that will break your Ansible scripts regularly as the system changes. Ansible is a huge mess and not suitable for the job IMHO.

With NixOS, the entire system is controlled by config, so there is only one source of truth for the state of the system, unlike Ansible. This is a fundamental flaw. Ansible is a hack on top of pre-existing setups.

With Nix, my system only gets more stable with time. It's the opposite of anything I've ever used, where systems get crufty and have to be reinstalled every couple years. Since the state of the system is fully determined by your config, you can always get to an exact state without a bunch of extra shit missing or added.

And the language isn't really that hard for anyone who's done a bit of programming. It's certainly easier than most general purpose languages, as it's static data 90% of the time with a bit of logic thrown in when needed.

fwiw nixpkgs has significantly more packages than arch (including the aur), and those packages are also significantly more up to date. No other repo comes close to nixpkgs in this regard. This has been the case for quite some years now.

https://repology.org/

I also like that packages in Nixpkgs goes through code review.

How many of these are duplicates or just multiple versions though?

Repology already attempts to account for that, and Nixpkgs normal policy is one version per package unless there are specific reasons for it to be otherwise. Nixpkgs doesn't duplicate packages just to have alternative build options or whatever like the AUR does.

iiuc the “non unique” section on repology accounts for this. nixpkgs is almost twice the size of the aur if you count like this.

> It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit.

That'll depend if you're on stable or not. If you're on stable and you need something from unstable that's also possible without any real risk of breakage on NixOS.

Also, once you've learned the ins and outs of Nix (which TBH I didn't find as hard as others, there's tons of examples) it's usually pretty simple to update software yourself--relatively risk-free. For example, I've been keeping Minecraft on the cutting edge for my kid by occasionally updating a URL and hash. A lot of the modules provide a 'package' option to make that easier.

Yep, a lot of the time it’s as simple as overriding the src and version of a given package -though if the package has patches to build on Nix it can be more work.