| Here's what's been key for me: Absolutely separate -- in your mind -- NixOS from Nix. The latter I've seen be a very useful tool that does what people here talk about: cleans up dependency and build and installation management in a reasonably nice way. The former is a religion/world-view that requires a complete mindset change, accepting a whole dogma, and differs entirely from how you're used to using Linux. I gave up and switched back to Debian after I couldn't get a decent answer on how to set it up easily with my github keys to easily, y'know, check projects out. The mental gymnastics required wer silly. Nix the language seems obscure at first but it's not so bad after a while. It's sort of got a bit of syntax tossed in from the ML-ish programming languages so there's some familiarity there, for me, maybe. Where it falls down is like anything else like this: it basically requires that all the things you dep on also adhere to this philosophy and have nix setups already or you'll be in a world of pain rolling your own. I gave up on converting our $work stuff when it became clear that the versions of flatbuffers and a few other deps we depend on just weren't out there in the nix ecosystem and I wasn't going to volunteer to make them. Anyways, I've seen it be very useful. A former employer used it to set up their whole Julia environment such that custom patches and configuration would all be nicely applied. And this was for both developer workstations and CI and production environments. It's a nice step below docker for doing that kind of thing, and is far less intrusive than docker in many ways. |
Maybe I'm a bad NixOS user, but I tend to run most of my development work through steam-run, unless the necessary default.nix is really simple. It works fine, and having the rest of the system be immutable is still an advantage.