It can work as a universal homebrew replacement (works on MacOS, Linux, WSL and can be easily ported to most BSD variants), comes with a huge collection of packages and produces its own reproducible source builds. Like homebrew, it's a hybrid source and binary based package manager (if you haven't done anything to modify the build, it will likely be downloaded from a cache of pre-built binaries). Unlike something like homebrew-cask, it will never download the pre-built .dmg file from the developer's website - with the obvious exception of proprietary software.
It can also work as a great AUR/ports replacement on Linux systems. Fedora doesn't provide FFmpeg or an up-to-date version of a package you need? No problem, just get it from Nix! All the advantages of a rolling release distro, without actually having to use one.
Due to its functional nature, it comes with a wealth of advantages over homebrew and other traditional package managers. Once you get past the learning curve, creating your own packages or modifying existing ones is a breeze. It can create disposable development environments with dependencies of whatever project you're working on, without having to install them in your system or user profile! Check out the Nix manual for more information.
It's so flexible that people have built a Linux distribution where your entire system configuration is a Nix derivation (package) - with atomic upgrades, rollbacks, reproducible configuration and much more! 
Essentially, all the benefits touted above apply here, but it is worth noting that Guix is a younger project. The author was originally a Nix dev, but found the DSL to be too awkward to use in practice, and opted to use Scheme through and through. Yes, Emacs bindings are available.
Also, Guix can now produce Dockerfiles, if that floats your boat:
The main allure to Nix/Guix is to be used for the internals of an OS. For example, NixOS is the most stable and maintainable system I have ever used, even though the documentation is absolute shit.
The reason I haven't is that NixOS is just so damn comfortable that I don't want to leave.
Guix devs themselves have hinted that "adding impurity to a free OS is much easier than removing impurity from a non-free OS", so I suspect they may not be categorically opposed to the idea of non-free packages.
It's so easy.
When I upgrade or (un)install a package, I get a completely clean fresh installed system. If upgrading my video driver broke my system, I can just pick the most recent version of my install from the bootloader. When I want to start writing code, I can use nix-shell to create an isolated environment with all the dependencies I need, and get to work, with one command.
At any moment, I know that my entire OS install is completely clean, devoid of any cruft, even if I have been installing and removing obscure software for months. I don't have a mess in /etc, in /usr/share, anywhere.
> I'm not reinstalling my OS regularly so I don't really see the advantage.
With NixOS, I'm never reinstalling my OS, because every update leaves me with a fresh new system, guaranteed.
Maybe you are confusing state mutations with fixed points, which are used extensively (thankfully).
I'm not a packager, but I can't read either.
I breezed through your explanation with great interest and became more curious than ever to try Nix out at some point - I've heard tidbits about it over the past few months and found it to be a fascinating project.
Then I read some of the other comments in this subthread, about Nix being Haskell and Guix being Scheme, and how the internals don't conform to the principle of least surprise within their development domains - and became sad.
On the one hand, there are going to be teething problems, that's fine.
On the other hand, if I'm learning a new package manager, I ONLY want to learn package management. My brain gets really confused if I don't stay highly domain-specific when learning new things. So if you present me with "you need to learn B to grasp and work with A" you'll just get a duck trying repeatedly to jump up over the curb and failing. Looks hilarious, maybe, but very impractical.
I don't know Haskell or Scheme yet, which puts a great dampener on me using Nix for a bit.
As another practical example, emacs and vi do greatly interest me (particularly emacs' flexibility), but I'm not interested in having to learn Lisp or memorize a Nethack labyrinth of single-character keyboard commands (and the scopes for what works with what and where).
I suspect I might pick up emacs at some point after I've played with Lisp/Scheme/et al for a while, but that's not right now.
TL;DR: It's a strain for me to learn new things (basically do anything that requires focus and can't be done with passive autonomy) if my mental stack already has anything in it. AKA, I have a monumentally stupid variant of ADHD that gives me learning difficulties.
That being said, NixOS is the best damn OS I have ever used. Period.
Installing NixOS is a total breeze. It's magical.
1. Boot live CD
2. Mount partitions
3. Write a simple configuration.nix
5. Boot a complete system, and log in with the user you defined in your configuration.nix (with a hashed password and everything).
nix-env lets you install packages in your home directory (without root).
nix-shell lets you create a special environment with specific packages, etc. and run a shell in that environment.
nixos-rebuild [switch test boot] (as root) creates a new system according to your modified configuration.nix. If you use switch, it (re)starts updated/new services all on its own. If you broke your system, just reboot, and pick the second most recent boot entry, and you will be back where you started.
TL;DR NixOS is well worth the effort. The benefits far far outweigh the headaches, and there is only room for improvement. You will start with a system that you cannot break!
I have my bookmarked set of gists to guide me through these things and it took me days to get it right the first time.
Also nixpkgs are a bit of a mess, you usually get a version of a package someone has bothered creating a PR for. This might be very old or bleeding edge. For specific versions you can be SoL. It is of course fairly easy to have your own .nix of the package and PR's are usually accepted quickly but the repo usually doesn't keep previous versions.
And then there is a whole world of pain regarding language specific packages. Python is especially painful for me.
It took me ages to find the page which hints at nix-shelling projects but this is a pita and requires a completely new workspace setup that is not compatible with people that don't use Nix.
Regardless I love NixOS, but to say this is perfect, not even close.
I've seen plenty of projects that were exceptionally well documented. Every method and class had inline docstring documentation, every module has a separate module docstring block. 100% PEP 257 compliance was enforced as part of the CI tool chain... helpful but only after I was sufficiently knowledgeable about the way the project was being used to get any benefit from it. The the sheer volume of documentation meant that many people had written extremely terse explanations, often devoid of any of the contextual information that would significantly improve someone's understanding of how the code in question was be used.
Point is... The volume of documentation or the percentage of documented features, has no direct bearing on its usefulness to any particular user.
I was personally donating monthly to Nix foundation for past few years, the maximum amounts that don't trigger tax concerns, but finally pulled my funding after the team continued to bury their heads in sand about state of docs for newcomers.
The main site docs are incomplete and reference style. The Wiki which had some use cases also had a banner saying it was all deprecated.
So you get newcomers who can't orient themselves, and even advocates like thomastjeffery in this thread who love it but months in still think the docs are wildly unhelpful.
Interestingly, guys who understand it very well are no longer capable of seeing the problem. They forgot what it's like to have no idea how any of it works, so can't describe the happy path between ignorance and the lightbulb coming on -- or even see that path isn't lit.
For now, the only way to walk that path is either absolute focus on learning it w/ no time for a day job, or have your hand held by someone enlightened (which is expensive for your MVPs compared to fixing the docs).
Where is this explained?
I am speaking from experience when I say the documentation is "absolute shit". Most of the useful documentation I have read comes from the deprecated wiki.
When I first installed NixOS, I had to read the source code for simple things like defining a user or getting samba set up, and still had to rely on the deprecated outdated wiki.
Three current state of documentation for NixOS is spread between the manual, deprecated wiki, and the source code itself. The manual barely shows how to get a simple system working, but as soon as you reach an edge case - which Nix itself is fantastically suited to handle - you have to start digging.
In time, documentation for NixOS will be mature and usable, but right now it is severely lacking, moreso than any other aspect.
One question: can I remove systemd? :)
Any particular reason you don't want it?
I've heard good things about Void Linux, I'll likely have a look at that at some point.
On the flip side of the coin, I've kind of accepted that everyone who uses Linux has to put up with systemd now, so I'll accept my fate eventually. It's just that I value constructive and positive communication, I don't like the systemd team's blatant arrogance, and I consider it a corporate abuse of power that nothing has been done to curb or deal with it. (I hope I never have to deal with Red Hat in a business setting. Feathers, sparks, fur... everything would fly, and it wouldn't be pretty.)
I have never had an issue with it. In fact, systemctl has been much more consistent for me than init services ever were.
- people talk about how rapidly they can perform complex edits with few keystrokes, which is something I most definitely can't do with Geany (a Notepad++ clone that made me wish Notepad++ worked on Linux); and
- it's a standard utility that you can generally expect to be available in some form on literally every UNIX (especially server environments).
So, basically I'm being pragmatic. I'm at the point where I'm wondering about building my own text editor (something I've wondered about for several years, actually), but that immediately introduces a software-installation problem if I want to be able to bring that editor to other machines.
I have a small modicum of knowledge about how to get by in vi, but it's extremely barebones - exiting, copy/pasting (I think the wrong way, heh), not much else.
I definitely could learn significantly more, but I just have a massively hard time fielding the idea of "okay let's play with the text editor for a few hours". Sure, once I was actually doing it I'd probably find it fun, I just can't convince my brain's broken scheduler that it's not actually a waste of time :D
As an aside: I'm wondering about building my own editor because I want something that can jump around text similarly to the Canon Cat and which has syntax highlighting and autoformatting similar to QBasic/QuickBASIC - and I'm frankly petrified by the idea of adopting a text editor that uses Blink for rendering. Blink (aka Chromium) is like Flash meets Java for UI design nowadays, it's almost like crack, and I want to do everything I can to stay as far away as possible from it.
This is not because the systems using it are not well-designed or -built, but because I fundamentally disagree with the philosophy and idea of using a Web rendering engine for tasks like communication or text editing. HTML5/CSS/JS/WASM is the world's biggest Rube Goldberg "safely run arbitrary code from remote servers" in existence; it wreaks enough havoc on the Internet, I don't want it leaking into my desktop too.
My main complaint is the W3C: they produce specifications that are too narrowly scoped and at too frequent a rate for the associated implementations to be operationally cohesive. The code for each feature in isolation might be excellently architected and written, but as a whole the amount of memory and CPU churn undeniably associated with rendering engines is significantly higher than would be found in platform-native (or even cross-platform) solutions.
You can definitely argue "well that's how things are now, the Web will improve as time goes by"; I'd argue that no, things have always been a mess in the Internet community, and nowadays the driving forces are all companies with advertising and/or consumer-consumption interests. This in itself isn't necessarily wrong, but it means that the focus is "is it good enough? okay, ship it" and there's no conservative holding back until what gets released is of extremely high quality.
EDIT: FOUND IT. This was the reference I was looking for about how the Internet's been crazy for years. The link referenced here is from 1998: https://news.ycombinator.com/item?id=10684426 (there's more commentary in the article itself - https://news.ycombinator.com/item?id=10682003 - the parent posts to the excerpt I linked were pretty big).
I have been using NixOS for a couple of months now, and still don't really understand how to write nix expressions.
Will it add the packages installed this way to rpmdb?