[AnIdiotOnTheNet]

I'm not asking it to be more 'orthodox', I'm asking to not have to spend months scouring poor documentation to learn a new language and toolchain to gain the very few benefits Nix provides over the existing systems. If Nix is so inherently complicated it cannot deliver that, then why would I want it?

Ultimately I want less complication in my life, not more, and Nix very much does not provide that from what I can see.

[e3bc54b2]

Traditional systems have complexity too. Its just not up front.

I like to compare it to fossil fuels and global warming. Traditional systems get one started quick, but eventually build a large fragile system that gets harder to fix/rebuild the longer it goes on.

Nix is different, it forces you to do your work upfront. But once setup, you pretty much can (and to my attestation do) forget it is in place. You do have to learn setting a anything a and everything. But you only do it once. If the house burns down, you don't need to remember what you had. You don't need to remember what to setup in what order. You don't have to find out you forgot something in the middle of something else. In other words, the onus is no longer on you.

That last sentence is incredibly liberating. I stopped worrying having black screens after updates and pretty much stopped having rescue disc, because rescue functionality comes built in the system. It sounds cultish, and it kinda is, but as I said in previous comment on Nix, it is the worst system management tool, except all the others.

[ris]

Oh, I use Nix because it does provide less complication in my life. It's just necessary to wrap your head around a few core principles first, which can be a little mind-bending when you start out (no fixed /usr locations? huh?)

[zeec123]

It is like saying I don’t want spending months to learn git to gain the very few benefits of a version control system. I much prefer to share my code with my coworkers via usb-sticks. Yeah this is less complicated in the short term.

[AnIdiotOnTheNet]

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.

[anandsuresh]

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?

[AnIdiotOnTheNet]

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.

[anandsuresh]

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.

[ris]

> 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.

[anandsuresh]

Nix operates at the cusp of some of the most complex and obscure parts of the technology stack: operating systems, compiler toolchains, and package managers. These inherently complex components require a fair bit of commitment to fully comprehend in order to be used well. You can get a lot of mileage skimming through some tutorials to become productive, but to really utilize it to its full potential requires a fair bit of investment. You don't have to be an automotive expert to drive a car, but if you're looking to race, it behooves oneself to invest the time it takes to gain the expertise.

Nix takes a very different approach to system configuration than the traditional ways. Because it treats the entirety of the operating system (bootloader, kernel, user-land, services, account management, etc.) as a single composable unit, it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone. The deviation from the Unix Filesystem Hierarchy is, IMO, required to make systems more composable and maintainable, and is inherently a good thing in the long run. Portable development environments eliminate "works-on-my-laptop" scenarios and ensure everyone on the team is always in sync with each other and CI/CD. Reproducible builds that can be rolled back after a botched deployment are a huge win. And delivering all of these features in a single tool requires breaking some of the old rules, and that is always met with resistance due to the inertia of "it works fine for me".

To be honest, there is no reason why you should give up what works well for you. Having said that, for those that are looking beyond the traditional tools like shell-scripts, Ansible, Chef, Puppet, and others, Nix offers all that is needed to easily build and maintain composable software stacks. Docker comes close to delivering some of the same features as Nix, but comparing the two is a bit like comparing system configuration using shell scripts to Chef/Ansible.

Yes; one does have to learn a new language and its idiosyncrasies. But that is also true of things like Rust. As a seasoned C programmer, I am able to write "good" C code. But that is not a statement about C's ability to scale to larger teams. Rust requires developers to give up their old ways of thinking and "give in" to the Rust-way. The longer you fight the borrow-checker, the more painful it gets. But once you give in, you are able to write code that is safer for use within large teams, thus delivering more momentum in the long run. It is not that it can't be built with C; it requires a communal way of thinking about software complexity that is forged by experience and tempered by camaraderie, and tools like Rust and Nix are excellent supplements.

I do agree with you that the documentation leaves a lot to be desired. I've always considered the FreeBSD Handbook to be the gold-standard for technical documentation and Nix has its work cut out to reach that stage of maturity. But I have full confidence in the Nix community's ability to deliver.

[pxc]

> it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone.

On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.