Linux

In this comparison, the devil is in the detail.

With Ansible, you have an initial condition onto which you add additional state through automatically executed steps dictated by you until you (hopefully) arrive at a target state. This all happens through modification of one set of state; each step receives the state of the previous step, modifies it and passes the entire state onto the next step. The end result is not only dependant on your declared steps but also the initial state. A failure in any step means you're left in an inconsistent state which is especially critical for the case of updating an existing state which is the most common thing to do to a Linux system.

In NixOS, you describe the desired target state and the NixOS modules then turn that description into compartmentalised bits of independent state. These are then cheaply and generically combined into a "bundle"; wrapping them into one big "generation" that contains your entire target state.
Your running system state is not modified at any point in this process. It is fully independent, no matter what the desired system is supposed to be. It is so independent in fact that you could do this "realisation" of the NixOS system on any other system of the same platform that has Nix installed without any information about the state of the system it's intended to be deployed on.
This "bundle" then contains a generic script which applies the pre-generated state to your actual system in a step that is as close to atomic as possible.
A good example for this are packages in your PATH. Rather than sequentially placing the binaries into the /usr/bin/ directory as a package manager would when instructed by ansible to install a set of packages, NixOS merely replaces the bin symlink with one that points at an entirely new pre-generated directory which contains the desired packages' binaries (well, symlinks to them for efficiency). There cannot possibly be an in-between state where only some of the binaries exist; it's all or nothing. (This concept applies to all parts that make up a Linux system of course, not just binaries in the PATH. I just chose that as an easy to understand example.)
By this property, your root filesystem no longer contains any operating system configuration state. You could wipe it and NixOS would not care. In fact, many NixOS users do that on every boot or even use a tmpfs for /.

(Immutability is a property that NixOS gains almost by accident; that's not its primary goal.)

Another aspect I like about Nix compared to what I understand from Ansible (which I used a bit but not much) is that your configuration describes your system without any hidden state. Yes, you only get your dependencies through full evaluation, but what I mean is this: Let's say you install something on a system, i.e. you add it to your list of packages, which you later remove. To my knowledge, Ansible won't remove the package if not explicitly asked. However, if you explicitly tell Ansible to not have it installed, what happens if that package is later introduced as a dependency?

Ansible will always operate on a stateful system, which is kind of the combination of what others have already mentioned – it's (EDIT: it being Nix) idempotent and there's no hidden state that will break something down the way.

I would separate NixOS from other immutable distros. NixOS is really about giving you blank slate and letting you fully configure it.

You do that configuration using a static config language that is able to be far more idempotent than Andible. It’s also able to define packages that are well contained and don’t require dynamic linking setup by manually installing other packages.

Immutable distros, on the other hand, really have no advantage to your setup and will probably feel more restrictive. The main use I see for them is for someone new or lazy that wants to get a working system up and running quickly.