> That being said a lot of smart people here and in my peer group swear it's the truth, despite none being able to elevator pitch it.
OK, I’ll bite.
Nix is a build system. NixOS is a Linux source distro built on top of it (cf Gentoo, gittup, BSDs). Except you won’t need to build anything.
Nix builds (should) execute in an isolated environment, thus the build artifacts are (ideally) bit-for-bit identical no matter where they were built. This means you can have a shared artifact cache (cf Bazel). Now for the clever part: in a distro, such an artifact cache is the same thing as a binary repo. Thus you are in fact using a (somewhat disk-space-hungry) binary distro until you want to patch something, at which point it transparently reverts to a source one (up to and including rebootstrapping the system compiler if you wish).
That’s the gist, but there are some more goodies on top of that.
First, none of this really requires a NixOS-only world. Thus, as an intermediate step, there’s Nixpkgs: a ports-like collection of packages that runs on conventional Linux and macOS systems (*BSD support is possible but has bitrotted). To maintain isolation in such an environment, all binaries it builds refer to dynamic libraries by build hash rather than load whatever’s present, and are usually wrapped to ensure other parts of the ambient environment don’t leak through. But once you’ve done that, more or less the only thing remaining to have a “gimme a shell with P, Q, and R in it” command is to point PATH to the right build directories. Hermetic build environments (cf virtualenv) for any supported language, user-scoped rootless package installs, good stuff.
Second, what NixOS adds on top of that (apart from a kernel) is a system for building system configurations out of Nix-language descriptions. It’s a bit clunky, like all config generators, but once you commit to maintaining all of your /etc that way a full rollback of (the NixOS-managed part of) the system is a single GRUB selection away. There are also things like “run a QEMU with this system config inside”, “build a Docker-compatible image with this system config inside”, etc.
Finally, as to how this works, Nix the build language is really simple, it’s JSON + (pure) functions + laziness + a build recipe type. Usually you just generate some shell or Perl or whatever scripts and stuff them into the recipe, so for Nixpkgs it’s honestly a bit overkill, but NixOS uses it to define a rather clever system with options that (if defined) set values of other options that ... all the way to the options that define the raw content of each file in /etc, with rules for merging option values if you wish (cf CUE, Dhall). If your mental model of your system is more abstract than the configuration of each individual service, it’s not hard to write it down as Nix code that defines some new NixOS options, then define your system—or several—in terms of those options.
Bad parts:
Apart from the build system as such, the CLI includes support for a lot of the idioms I mentioned above, so the separation may not look that clean. (This is not helped by the fact that a complete CLI overhaul is in progress, with old commands like nix-build and nix-env being superceded by a single new one, nix. The nixos-* ones are separate for now.)
The language is perhaps a bit too minimal and lacks a standard library, so Nixpkgs ends up containing that as well, without much in the way of documentation. You will have to refer to the source there. The library is mostly simple list and mapping utilities, so it’s not difficult, but figuring out whether the thing you want is in it or not can be frustrating, and the API won’t win any beauty contests.
It can be slow.