I’ll give a short talk about NixOS in a few weeks.
I want to focus on one big thing, I have come to the conclusion:
Functional purity etc. was high on the list (I am a FPer). Declarativeness also beats reproducibility (both are tied together, cannot do one well without the other) - even though it’s only number two on the list on NixOS.org (it should be number one!!)
Declarative configuration is just such a beautiful feature.
NixOS is always in a clean state. (except for a few things in /var/ that may have side effects), but it’s mostly due to the declarative configuration, so I don’t know if that counts 
It’s also quite light, as you can just use exactly what you need, this could be improved by spending time stripping extra libs.
I agree that declarative config is probably the best feature of NixOS. Most of the other features only derive their value from it.
That said, not mentioning the reproducibility and what @Solene calls the “clean slate” risks making NixOS seem like just another ansible or chef. NixOS’ “purity” (by some definition of the word) is what ultimately sets it apart from those alternatives.
And I think this purity is what makes it so, so much better than alternatives.
So in absolute terms, yes, declarative config should be the standard, really. Relatively, though, NixOS’ core competency in comparison to other tools is that you can apply a different config tomorrow and still expect to know what you deployed.
All v good points - I will add them to my talk.
I agree - “declarative” risks becoming a discussion about syntax - which is literally the worst argument in tech!
But of course NixOS offers the real deal. The system doesn’t diverge from the configuration (unless your disk is corrupted, or you get hacked or whatever).
Then there is also the counter part of “NixOS worst features”
It’s easy to sell NixOS until people encounter these two issues.
That statement is mostly true…
We have some ensure* options which allow your configuration.nix to deviate from your actual system configuration.
Anything that starts doing stateful operations needs to be carefully handled to work properly.
You can remove packages from your system with little to no leftover and without breaking some other dependency chain.
“Remove packages easily” is the other half of nix-shell -p, I guess, which would be my own answer. (“The language is dynamically typed and lazy” would be my worst feature.)
Purity and declarative configuration are the heavyweights, but here are some other nice-to-haves (mostly for Nix, not NixOS specific):
You can have multiple versions of the same program or environment downloaded at once, without relying on hacky tools like rbenv, nvm, pyenv.
Whether a program is “installed” versus “downloaded” are treated as separate — i.e. if it’s required to be “installed” but not in the nix store, it will be downloaded/compiled and added to the store. If it’s not actively “installed” but in the nix store, it can remain cached for the next time it’s activated unless it’s purged by garbage collection. This means scripts can pull their own dependencies and your system doesn’t accumulate junk over time.
Packages can be downloaded as cached binaries or patched/compiled on-the-fly, with each layer of dependency also cacheable (à la Docker), so you get the power of Gentoo with the speed and usability of… not Gentoo.
Ability to build, test, or try out a VM of your system without switching to it entirely. Rollbacks are nice, too.
I agree with what you all said but for me, the killer feature is that you configure your system using an actual Turing complete programming language.
Every time I see people argue that it gives too much power to hurt yourself (in other contexts), they usually get to reinventing the wheel by adding a templating layer on top of what they use. My latest experience of this is with Kubernetes (yaml configs) and Helm charts (templating). I also see sometimes articles talking about yaml anchors as a good thing since it’s DRY. And I agree, templating is a first good step! But why stop there?
I’m working on using NixOS + disnix to configure my home server and being able to create reusable building blocks using functions is so nice IMO.
https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-management-methods/
I liked the terms this blogpost describes:
“divergent” for if the system management tool doesn’t give you any knowledge about the resulting state,
“convergent” for the tool aims for a particular state, and tries to get there,
“congruent” for that the tool is forced to be in the target state.
Reminds me of this:
I don’t necessarily agree with the author’s argument; but I interpret the diagram as “if you only focus on the benefits of an alternative in order to avoid the drawbacks of your current solution, it risks ending up in a cycle”.
Very nice article, those terms capture a lot of my thoughts on the topic.
One thing to note on NixOS vs other congruent systems is that it doesn’t require a “host” that is managed by another mechanism, unlike the various image-related tools out there. This may be another “best” feature to point out, when comparing to similar tools.
- declarative configurations are the biggest deal
Functional purity etc. was high on the list (I am a FPer). Declarativeness also beats reproducibility (both are tied together, cannot do one well without the other) - even though it’s only number two on the list on NixOS.org (it should be number one!!)
I think this reflects where Nix has grown the most. (e.g. from the 2022 Nix Survey Results, 80% of the respondents use NixOS).
Rather, for two families of use cases:
(1) manage how a team’s software is moved about.
(2) manage the software/setup on my computer.
The norm for (2) is just using a package manager to install packages & its dependencies; and ‘beating’ a system into shape by directly editing the configuration files which get read. – Some non-Nix solutions people use include “having a notes file to keep track of what I should install on a fresh setup”, or maybe using filesystem snapshots or just re-installing the entire OS if something goes wrong.
The norm for (1) these days tends to be Docker containers, and prob’ly Kubernetes to orchestrate that.
The ‘risk’ of using Nix is that you might not know how to get what you want done with Nix. In (1), it’s a whole team that has to pay that risk, whereas with (2) it’s just you. (That nix can be difficult somewhat restricts it to enthusiasts atm; which is not really an issue for (2)).
In terms of benefits Nix can offer each; for (1), copying images may not be elegant, but it works; for (2), yeah I think this is where the “declarative” / “as code” is compelling compared to what others do. – I think this is why I see much more excitement about Nix flakes, than about tools (say) NixOps or the nixos image generators.
My favourite ‘elevator pitch’ of Nix is “it’s like Docker, without Docker containers”. (nix run is like docker run, but you don’t have to fuss with volume mounts…). Next would be thinking of NixOS as “like terraform, but for the Operating System’s configuration”.
Reproducibility is foundational, though; even if it’s not as sexy. – I do remember it was always a pain to go back and touch some side project after months/years, since the first step would somehow often be a chore to update the project following updates to the system’s package repository. I like relying on Nix to avoid having to do that.
I don’t remember who said this, but reproducibility and immutability are the killer feature for me:
With Nix, things you fixed stay fixed.
If you use Nix/NixOS correctly, it will never update away the rug under your feet, as opposed to every other system I’m aware of.
Using it correctly is non-obvious though. I think this is because both the fundamental problem Nix is able to solve and the specific solutions the Nix ecosystem presents are not collectively understood well enough (on average, but at the boundaries also in absolute terms) to present those solutions in a straightforward manner. This is why I‘m working on documentation and support all efforts clarifying the existing results and the process of obtaining them.
Very good content, thanks for sharing
My favorite feature is adaptability and hackability. Hacking on NixOS requires some expertise, but I think the surface area of that expertise is smaller than a traditional distro. You need to learn an unusual language but after you can overcome that you can trace the explicit relationships in the system to figure out how it works. I think traditional distros require more implicit knowledge, which is a problem that is obvious to an outsider or a beginner but not something you think about after several years of using Unix.
Making everything explicit and functional makes learning more straightforward and therefor more hackable, but it also means that if you make a change somewhere you can be confident that change will propagate. After experiencing Nix I have no tolerance for things that require a make clean; make all.
This is a golden thread 
Tagging some of the marketing team folks as well @tomberek @garbas
I agree with everything on the thread.
Adding a small point from what I’ve been gathering, there is a split though in regard to reproducibility.
There is a good portion of the external (non-Nix) dev community that are less familiar with reproducibility and its impacts, which significantly reduces their perception of the value. Those that are familiar were very quickly able to recognize where it benefits them and how Nix is set up to support it.
