The difference is, you can create proper abstraction modules that put everything together, from dependencies, to config files, firewall rules etc and have nice options for your abstraction.

No other system provides this in that sane way. I used countless configuration systems, from custom bash hacks, ansible, chef, puppet, salt - I have seen a lot.

Nix is just on another level. Never going back

▲

unshavedyak an hour ago | parent | next [-]

My problem with those abstractions is:

1. That the error messages for them i find to be awful. They really need to take inspiration from Rust to help users know exactly where the API error is happening relative to your code. I've spent quite a lot of time toggling things on and off to try and find which part of code, or which package, is causing a specific failure.

2. I've not found the APIs that the abstractions provide to be stable in the same way my Rust crates/etc are. Something can randomly break between updates and i'm not sure what caused it. Takes me quite a while of digging through source to find the root cause, and digging through Nix source i find extra painful.

All around i hate this side of Nix. A lot. However it's enough of "another level" that i stay with it and don't switch away.. I use it for my Linux machines and my Mac laptop. It makes so many things so easy, the majority of the time.. but when something goes wrong.. it's super painful.

	▲	packetlost 33 minutes ago \| parent [-]
		As someone who up until recently would have agreed with you, both of these are fundamentally familiarity issues. Nix's error messages really aren't that bad, but chances are there's exactly one line out of 200 that tells you what's wrong. Learning to read stack traces for a new language is part of learning that language. I've not had issues with Nix APIs, at least not Nixpkgs or the language builtins. When something does break for me, it's usually some random JavaScript package that had some external dependency change. Nixpkgs is pretty well organized and I find navigating it not that hard once you read the packaging guidelines. find / fzf / ripgep / etc. are all great at this, as file and folder names are critical to the organization of nixpkgs. The big turning point for me was trying to build and package a non-trivial application and build a NixOS module for it.

▲

rgoulter 5 hours ago | parent | prev [-]

> The difference is, you can create proper abstraction modules that put everything together, from dependencies, to config files, firewall rules etc and have nice options for your abstraction.

Yes, this is an understated benefit.

The declarative interface is nice.

That NixOS configs are modular allows you to create those abstractions. -- In the same sense terraform modules are "infrastructure as code", NixOS modules are "system configuration as code".