Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?
Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?
But the thing about Nix is that it just adds even more complexity. As was mentioned elsethread, in order to be effective with Nix you need to understand all the complexities of Nix and Linux. And the thing about Linux is that we have a ton of adequate recipe books out there already.
Nix offers a way to easily customize and override said "reasonable defaults" across packages written in different programming languages and compiled using a variety of build toolchains. Doing so requires using a common language for expressing defaults and overriding them. IMO, that is not adding complexity, but taming it to make it reasonably easy for individual developers and teams, small and large.
I'd argue that the traditional stack relies on way too many tools, each designed for a limited purpose, and making a LOT of assumptions about the target system. This IMO is far more complex than learning one language and framework.
It absolutely doesn't. I'm someone who is fairly fluent with Nix, and in comparison the complexities of running a non-trivial docker-compose setup gives me nightmares. Luckily I basically never have to worry about that though.