Haskell developer experience in NixOS

This is mostly about NixOS and not the Haskell experience (though some of this applies to that as well).

TL;DR: I install a lot of packages to try them out and want an easy way to roll them back with as few consequences as possible. Nix seems to fill that gap.

As a student this really appeals to me; I usually think in broad terms initially, maybe write a proof or two to make sure I'm doing what I think (read: hope) I'm doing. Implementation is an afterthought for me, and so when it finally comes time to implement something I'll usually start at the typical "what are my options" phase.

For domains that I'm strong in I have a good idea what's available and it's probably already installed. But sometimes you're just /new/ to something and need to try things out. Sure, an API seems good in theory, but how does it work out in practice? Too much boilerplate? Does it work well with everything else I want? Did/does the original author share similar use cases to me? Is it (well) maintained (still)?

Of course, by the end of this process any number of things could be installed; both things I asked for, and things I didn't, are available to me. The issue that I then run into, and that Nix seems to solve for me, is that I want to undo portions to the installation and all their unintended side-effects. Beyond that, an easy way to manage groups of packages and roll them back en masse (again, including unintended side-effects) would be so beautiful.

In the case of Haskell, I have created chroots just to keep Haskell penned away from the rest of my system. I don't need pacman yelling at me because I `cabal install`d something and now the owner is wrong, my hair is on fire, and the universe is imploding. Nix seems like a much better way to handle this.

Of course, I could just be naive and/or uninformed-- likely both. I'd welcome sage wisdom from Haskell programmers on how to properly, cleanly manage package installs without getting in trouble with the system package manager (short of creating packages myself). And I've no doubt this has been solved outside of Nix using methods beyond rigorous self-control.

I'm not a Haskell developer nor Nix user, but I find Docker is surprisingly convenient, if only for its immutable layers file & build system: as I test different packages, I only pay for what's changed or removed, not the full setup. For example, for a C library, you might start with

    RUN apt install -y build-essential
    RUN apt install -y libopenssl-dev
    RUN cd src && ./configure

but if libopenssl-dev is the wrong package, change that line, and rebuild, and the build-essential installation isn't redone, only what's change and subsequent lines.

Any sort of snapshotting at file system level (e.g. ZFS) would do the job as well, but Docker puts it together in a convenient way.

I guess Nix is better by using a DAG, but it's probably more complicated and harder the reason about (at least for those of us lacking in headspace).

Those docker commands will install whatever binaries happen to be in the repository at the time they were run. Nix offers deterministic reproducible builds. A non-deterministic build is much harder to reason about.

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid these through careful scripting and pinning things, this is what Nix makes really easy: just pin your nixpkgs version, and you can almost guarrante that you'll get the exact same build years later and you can still change parts of it if you need to.

What is the significance between then and now for nix?