[XorNot]

Nix makes everything else so hard that I've seen problems with production configuration persist well beyond when they should because the cycle time on figuring out the fix due to evaluations was just too long.

In fact figuring out what any given Nix config is actually doing is just about impossible and then you've got to work out what the config it's deploying actually does.

[mschwaig]

Yes, the cycle times are bad and some ecosystems and tasks are a real pain still.

I also agree with you when it comes to the task of auditing every line of Nix code that factors into a given system. Nix doesn't really make things easier there.

The benefit I'm seeing really comes from composition making it easier to share and direct auditing effort.

All of the tricky code that's hard to audit should be relied on and audited by lots of people, while as a result the actual recipe to put together some specific package or service should be easier to audit.

Additionally, I think looking at diffs that represent changes to the system vs reasoning about the effects of changes made through imperative commands that can affect arbitrary parts of the system has similar efficiency gains.

[throwawayqqq11]

You are describing a propper dependency/code hierarchy.

The merging of attribute sets/modules into a full NixosConfiguration makes this easy. You have one company/product wide module with a bunch stuff in it and many specialized modules with small individual settings for e.g. customers.

Sure, building a complete binary/service/container/nixos can still take plenty of time but if this is your only target to test with, you'd have that effort with any naive build system. But nix isnt one of them.

I think that's the real issue here. Modularizing your software/systems and testing modules as independently as possible. You could write test nix modules with a bunch of assertions and have it evaluate at build time. You could build a foundation service and hot plug different configurations/data, build with nix, into it for testing. You could make test results nix derivations so they dont get rerun when nothing changed.

Nix is slow, yes. But only if you dont structure your code in a way to tame all that redundant work, it comes around and bites you. Consider how slow eg. make is and much its not a big issue for make.

[jacquesm]

I think for actual Nix adoption focusing on the cycle time first would bring the biggest benefit by far because then everything will speed up. It's a bit like the philosophy behind 'Go', if the cycle is a quick one you will iterate faster, keep focus and you'll be more productive. This is not quite like that but it is analogous.

That said, I fully agree with your basic tenet about how systems should be composed. First make it work, but make deployment conditional on verified security and only then start focusing on performance. That's the right order and right now we do things backward, we focus on the happy and performant path and security is - at best - an afterthought.

[xeonmc]

Sounds like it’s a gap that AI could fill to make Nix more usable.

[mschwaig]

If you make a conventional AI agent do packaging and configuration tasks, it has to do one imperative step after the other. While it can forget, it can't really undo the effects of what it already did.

If you purpose-build these tools to work with Nix, in the big picture view how these functional units of composition can affect each other is much more constrained. At the same time within one unit of composition, you can iterate over a whole imperative multi-step process in one go, because you're always rerunning the whole step in a fresh sandbox.

LLMs and Nix work together really well in that way.