Can I chime-in with a “to the core” explanation.
Linux ecosystem & IT as a whole - is a huge “bazaar” development process. It creates a structural mess as a biproduct. There are ~20 package managers & ~+100 central distribution software repositories.
The biggest repository that is famous for being usable & have almost all of the software packages - is Arch Linux sidekick AUR (Arch User Repository). AUR has 1 major design flaw - every package needs(encourages) a separate repository just for that package configuration, & so only one particular maintainer of that repository & package (the strong “bus factor” there - maintainer is not responding - nobody can do anything about the package), all package configurations are a separate configuration. It is a bit of a hassle to contribute to AUR - because every time the new repository must be cloned & the patch is on the mercy of 1 particular person in the world giving attention to the patch.
In the DevOps/SRE space - specialists need to learn/know several hundred tools & ~20 domain-specific languages to put all that together. Docker, Ansible (great language but not centralized), Hashicorp (HCL - great language), Kubernetes (its overengineering complexity of configuration & its repetitiveness & formatting - is what drove me away from DevOps, apart from learning & understanding the main classical DevOps tools language - Go) - it is just a beginning of what DevOps/SRE is about - a 50% of a job there is putting things together & keeping updates to those parts in sync with one another, it is a job largely about “bridging the gap” in structural disorganization.
Main DevOps/SRE invention is keeping infrastructure as a code.
& here comes Nix.
Nix language is (because of its scientific properties of it) - is a powerful language, it to put simply - infinitely programmable. So “infrastructure as a code” can be achieved (from the beginning - downloading, configuring, installing a package; to the end: managing a 1 000 node cluster deployment of servers with 100k “containers”, on cloud provider (& its services) running an enterprise software services that is the main source of company money). Nix language “laziness” allows to put all configuration for the world of software into 1 repository & grow the codebase there infinitely. So the world of people can pile-on unto 1 repository & polish & polish it & maintain it. Changing 1 structural thing in Nixpkgs - affects not 1 package, as in AUR - Nixpkgs maintenance allows to do a sweeping functionality introduction, compatibility changes & refactoring changes - across the whole world of computer software at once. The only caveat of it - is that Nix language & its complexity & complexity of a tooling, working with it & consequences of a design approach.
Nix gives DevOps/SRE a completely new perspective. No DevOps/SRE ecosystems except NixOS (NixPkgs) options - have that level of being a 1-stop candyshop for infrastructure automation deployment:
- Kubernetes: NixOS Search - Loading...
- PostgreSQL: NixOS Search - Loading...
- Grafana: NixOS Search - Loading...
- Haskell: NixOS Search - Loading... & Hoogle server: NixOS Search - Loading...
& It is not only DevOps/SRE options, those options are suitable for any deployments, so they also provide just as good Desktop configuration as well.
Those Options get a (now standardized) crowd-maintenance from a worl-wide network of according narrow-specialized professionals, & further general Nix code maintenance is done by NixPkgs maintainer teem as a side-gig of NixPkgs updates & refactors.
Nix puts Open Souce idea of “contributing through scratching one owns itch” - into a proper position, if someone does something - that is contributed to & immediately but gradually used by everyone - so the more people - the more correction & quality. Because of paradigms & context - “quantity transforming into quality” is the most strong here.
I also see NixPkgs as a main testing ground for open source projects being done right. On the integration of a package - if there is any assuming infrastructure/configuration hardcode - it would be found & reported upstream to be fixed. In that way NixPkgs (& Hydra) is a CI for compatibility & portability of software.
Nix actually has no competitors in DevOps/SRE field, no comparable products (besides GNU GUIX that sadly does not has the scale required & enterprise views contradict freedom of software license frequently). Only Nix combines multiple abilities that other solutions adopt into old paradigms through containerization, deduplication, FS snapshotting, jailed package bundling - but all those solutions is a patch-work that is even more diverse & complex than the Nix ecosystem, moreover that approach can not rely as strongly as Nix on crowd-source management of those solutions as one whole.
In business terms, Nix is not “just” “visionary” - it also has an objective scientific & technical superiority and solution got to the level - that further it only can grow and disrupt the market of IT infrastructure management & deployment.
To give some proof that it does a proper science-technical leap is: Graphs - Repology
The complexity of Nix maintenance & tooling is another topic - “errors were made” there & Nix ecosystem bears consequences & tries to solve them.
And Nix is a technical needle, also because of those “errors were made”. Companies can pick or classical DevOps, or Nix DevOps - having two at the same time require the ability to attract & hold a too highly skilled specialists that are few and far between & demand a lot from them. Once a business deployed NixOS infrastructure - in simple terms - it requires or to be torn down, or new deployments to be NixOS also & so hire NixOS DevOps’es. It locks-in companies hard on the stack.
So Nix has all needed to disrupt, seize & hold the market for a long time.