I honestly don't want to learn git precisely because there are version control systems that accomplish the things I need in a much simpler way. I only bother using git at all because some FOSS projects I've worked with use it. Hell, my impression is that most people who use git don't bother really learning it, they just keep a recipe book of how to branch, commit, etc. and then rely on stack overflow to un-fuck the repo after they accidentally blow it up.
I could not agree more. Most people, IMO, are workflow junkies! It doesn't matter how good/bad/ugly the tool is; if it works, it stays forever! And git is a perfect example of a tool that is complex, but survives because it became the gold-standard for FOSS.
Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?
Yes and for the same reason: people don't want to deal with systems that are overly complex for their needs, and OS configuration (especially in Linux) tends to have a ludicrous amount of needless complexity.
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.
Complexity exists and is going to get worse with time. The root cause is the prevalent software development paradigm: millions of developers/teams working simultaneously on different parts of the software stack, with an imperfect understanding of an ever-evolving system. "Needless" therefore is a matter of perspective. Reasonable defaults and recipes are a proposed way of dealing with said complexity, but what is reasonable is again based on imperfect understanding, and is therefore only going to work under specific conditions that are not written in code.
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.
> But the thing about Nix is that it just adds even more complexity
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.
