@oscarmlage What the two have in common is that they are built around the ideal of "declaratively specify what things should look like, and it Makes It So".

There are significant differences in how they accomplish those things though:

Ansible is designed as a system manager. It expects to be imperatively changing stuff about a (Linux) system, specifically in networked scenarios. It does not make the system itself.

Nix, on the other hand, is designed as a *build system*. It produces reproducible build artifacts from a given deterministic specification. But, unlike most build systems, the scope of *what* it can build is very broad.

A configuration file is a build artifact. A software package is a build artifact. An ad-hoc shell environment is a build artifact. An entire NixOS system is a build artifact. All of it is just build artifacts referencing other build artifacts, with each artifact being (sort of) content-addressable.

This means that Nix is a far more generic tool than Ansible is (and anything it needs, it can just conjure into existence, because it's a build tool!); but it also means that for specific *kinds* of builds, you want additional tooling to use *with* Nix.

For building software as well as a whole NixOS system, that additional tooling lives in nixpkgs. For building "an entire cluster of systems", that tooling is morph, NixOps, and so on. They all just do different kinds of builds, and Nix itself doesn't care about the distinction between them.

This is how you end up in a situation where Nix looks like Ansible, but it also looks like `apt`, and it also looks like `make`, and it also looks like `npm`, and a whole bunch of other tools. All of those are really different kinds of specialized build systems, and Nix implements those mechanisms generically!

The downside of that is that because Nix can do basically everything, there's not one obvious "hot path" for how you use it, and so you'll have to figure out how to use it for *your specific usecase* rather than just following a "getting started" doc like for Ansible (which only has one usecase really).

That's fixable with better and more comprehensive documentation, of course, but as it stands, there's a lot of work left to do there.