The future of software is Nix in the same sense that the future of software was Bitkeeper.
It was readily apparent to anyone using Bitkeeper that this was the right way for version control software to work. Similarly, the Nix model is clearly correct.
But just as Bitkeeper was a clumsy early attempt at implementing that paradigm, so is Nix. The article says that "Nix is declarative" which could not be further from the truth. It has a confusing and awkward language with multiple ways of accomplishing the same task, twisting concepts like "function" and "struct" into confusing knots that make it difficult to follow. Debugging is nearly impossible, and even test evaluations take a lot of work to get right. It is riddled with conventions and "helpers" that have idiomatic forms that are not well-documented and frequently abused.
But the model is RIGHT. This is the way to distribute software, this is the way to write software, this is the way to ensure hermetic distributions, this is the way to avoid global implicit state. And Nix as a proof of concept is great because it shows that it does work (basically).
So what is the path forward? Kill the language and replace it with configuration, with external scripts to do the heavy lifting. Make mutations of the data model the fundamental operations rather than having an intentional CLI that conceals the underlying functionality. So make it less usable but more understandable (like the path that Git took) and iterate from there.
It feels like there might still be time for Nix to morph into something that can get mass adoption. But it probably requires some radical technical changes and the controversy around flakes (which are incredibly useful) suggests that the existing community might not accept that.
Whatever comes next, IMO the killer feature will be that it enables rock solid developer tooling. LSPs that work; typed inputs to modules; control of deployment of NixOS machines and so on.
Back in the day, adopting Git was also clumsy and hard to implement. It was buoyed significantly by the investments GitHub made into its usability.
I agree Nix is going to have to evolve to gain wider adoption. It's part of the work we're seeing in the ecosystem, and also work we're already doing :).
I mean in a sense it is a skill issue, in the same way that humans haven't found the mathematical secrets of the universe is a skill issue. At some point you just gotta say this is too much for an average developer. Heck such a generic tool should be usable even by substandard developers.
> Kill the language and replace it with configuration
No. Hard no. Please don't tell me you are going to kill a fine (even though awkward) configuration language and replace it with (potentially text-templated) yaml.
I think I would rather replace it with a spec for derivation files implementable in any language that existing build systems can hook into
and use as outputs.
make derivation
python -m build derivation
Trying to package software with dependencies that don't exist in nixpkgs is painful despite the tooling existing to build and install them.
I really like Nix package management. I really hate Nix configuration management. I already know how to configure everything. I don't want to have to figure out whatever abstracted config options some random package maintainer decided on.
I feel that. This is one place where the "nix is everything, everything is nix" mentality hurts the project. NixOS modules are where the abstract config option sauce lives. It isn't an inherent part of Nix.
As Nix (and NixOS) becomes more widely used, this is one place where we'll have to find a way to let users do what they know how, and stop getting in the way.
We have Nixstan on "Ops Team" who keeps pushing us to use it. We haven't seen need that much.
So can someone give me elevator pitch that if we are CRUD Web App, why Nix instead of Puppet/Ansible + Docker Containers?
Also, this from the blog article: "What if adopting Nix didn’t irritate your IT or security teams?" Too late, security team is already pissed. They did some scan, we pinned a package, it has 3 high severity and it needs to be updated tomorrow. So yea, we are just yoloing package updates, we don't have much of a choice.
Oh yea, we have some third party proprietary package we use. Support told us, Red Hat/Rocky/Ubuntu or we could kiss support goodbye. Any suggestions that doesn't involve shoehorning nix into Ubuntu which is like mud wrestling with a pig?
FWIW, the post looks more like a startup pitch from its founder than a more technical article.
My take as of now is that I like what Nix achieves, but I don't feel the complexity is worth it. Docker and similar container tech have issues, yes, but I'd have way way less trouble onboarding a dev on it than Nix.
Hear hear. It takes continuous effort not just on documenting, but also reducing the need for documentation by cutting interfaces and accidental complexity.
> To make a smooth path from “Nix could solve my dev, build, and configuration management problems” to “Nix is solving these problems” and in a way that doesn’t involve turning someone from a developer to “the Nix person.”
When do we get Nix easy enough for not just software engineers, but also scientists etc who need reliable reproducible systems for running simulations with zero hassle?
Something I have never understood is why the hard-on with Nix, and Guix is not heard of even a tenth of the times. Is GPL really so repulsive to the masses? Or the libre kernel default?
I think guix was just late to the party and the extra steps to setup the nonguix for the non free software like steam is enough of a deterrent for users to go to nix instead.
I use guix myself and prefer its use of scheme. I don't mind having a little less guidance and "how-to" articles available if I'm trying something new because I'm comfortable reading its codebase.
I agree that Nix is the right idea, but I'm hesitant to adopt it right now because (i) rough edges like poor documentation and inconsistent interfaces make it feel immature, (ii) things are moving very fast with experimental stuff like flakes, which means it will take a while before Nix starts to stabilize, and (iii) recent community forks like Lix might create a fragmented ecosystem in the long run.
As a response to (ii), I assure you that things are most certainly not moving very fast with experimental stuff like flakes. Flakes were first released as "experimental" almost 3 years ago and have been stuck in feature purgatory ever since.
To be blunt, this is driven by the rejection of flakes by a significant group of the contributor base, despite it being much more adopted by the user base at large.
Even as someone who does think Flakes are better than the prior solutions, I'm increasingly of the opinion that Flakes would be better moved to a layer outside the core Nix project - advancing them within core Nix at this stage seems pretty impossible with many within the project opposed to their existence. I think if Flakes were an alternative project at the same level as something like Niv, a lot of the holy warring would get out of the way.
1. Those who wish to improve them could do so without the discussion being deadlocked by "hey, we haven't yet agreed these should be stable"
2. Those who don't want to paint them as the path forward for fear of precluding a better option, now don't have to.
Regarding experimental features like flakes: the reality is they're incredibly stable. I've written about this before: https://determinate.systems/posts/experimental-does-not-mean.... They haven't realistically changed in years, because they work so well. The experimental label is practically FUD at this point.
If the Nix team were to change flakes in a breaking way, it would be stunning neglect for the vast, vast percentage of the ecosystem that has already adopted them. Our data shows that of all the (OSS) repositories created every day, almost 90% of them start with a flake.nix. Of all of those projects, less than 20% use the legacy file formats, and most of those are using the flake-compat library.
On documentation and interfaces, I agree, and we and the greater community are working hard to on that problem. I'll take time, but it is decidedly better than it was a few short years ago.
And on community fragmentation, I just don't see it becoming a problem. The core Nix ecosystem is so large and diverse, I don't see meaningful fragmentation coming out of this.
Because the future of software isn't on Windows. Even Microsoft realizes that with MSSQL moving to Linux (and dying), .Net recommended on Linux and internally, vast majority of workloads that can run on Linux are doing so. Apparently, a ton of Office Teams architecture is Linux.
There is some work to get nix to work with Windows, this is mostly being done by john ericson.
However, the real issue is that nixpkgs (the repository containing all nix expressions) heavily assume unix paradigms.
There could be a "nix-windows repository" in the medium to far future, but it will likely be very divergent from the current nix+nixpkgs story of today.
Well. The future isn't evenly distributed yet :). There is work in flight to make Nix support Windows. Also, and I know this doesn't count, but it works great in WSL today.
A FlakeHub organization with private flakes and cache is $20/user/month, plus at-cost storage and bandwidth. Members of that organization get automatic access to the private flakes and read access to the cache. In the future, we'll be opening up the policy engine to make it more flexible.
They're great! But also still miss fundamental pieces that Nix gets right. Especially the way the build and dependency graph goes right to the root of every package, and comes together to completely describe the system you're running today.
Similarly in English. I think "nix", like "git", is a self-deprecating name. It's a play on both "nix" -- to cancel or to not exist, and "nix" as the suffix for Li- and U-.
It also means nothing in English, though that's somewhat obscure from my perspective. (Looking it up, it sounds like English borrowed it from German a while back.)
In English I think it's most often used as a verb that means basically to cancel. Like, "We're running out of time, we should nix feature X."
The future of software is Nix in the same sense that the future of software was Bitkeeper.
It was readily apparent to anyone using Bitkeeper that this was the right way for version control software to work. Similarly, the Nix model is clearly correct.
But just as Bitkeeper was a clumsy early attempt at implementing that paradigm, so is Nix. The article says that "Nix is declarative" which could not be further from the truth. It has a confusing and awkward language with multiple ways of accomplishing the same task, twisting concepts like "function" and "struct" into confusing knots that make it difficult to follow. Debugging is nearly impossible, and even test evaluations take a lot of work to get right. It is riddled with conventions and "helpers" that have idiomatic forms that are not well-documented and frequently abused.
But the model is RIGHT. This is the way to distribute software, this is the way to write software, this is the way to ensure hermetic distributions, this is the way to avoid global implicit state. And Nix as a proof of concept is great because it shows that it does work (basically).
So what is the path forward? Kill the language and replace it with configuration, with external scripts to do the heavy lifting. Make mutations of the data model the fundamental operations rather than having an intentional CLI that conceals the underlying functionality. So make it less usable but more understandable (like the path that Git took) and iterate from there.
There's nothing wrong with the fundamentals of Nix.
But working with nixpkgs is quite difficult for most. Which is why I'm attempting to address those issues in a fork, Ekapkgs.
The repos will eventually expose optional flake entry points, so it will be compatible with flakes and non-flakes.
If you're curious, https://www.reddit.com/r/NixOS/comments/1gatci0/announcing_t....
I love your project, Jon! I think the Nix ecosystem will be improved by having more, smaller things, where the boundaries are clear.
It feels like there might still be time for Nix to morph into something that can get mass adoption. But it probably requires some radical technical changes and the controversy around flakes (which are incredibly useful) suggests that the existing community might not accept that.
Whatever comes next, IMO the killer feature will be that it enables rock solid developer tooling. LSPs that work; typed inputs to modules; control of deployment of NixOS machines and so on.
Back in the day, adopting Git was also clumsy and hard to implement. It was buoyed significantly by the investments GitHub made into its usability.
I agree Nix is going to have to evolve to gain wider adoption. It's part of the work we're seeing in the ecosystem, and also work we're already doing :).
I use NixOS in spite of the Nix Language. It's worth it.
Of course -- as do I. But I've become unwilling to accept that the failure of the Nix language is just a skill issue.
I mean in a sense it is a skill issue, in the same way that humans haven't found the mathematical secrets of the universe is a skill issue. At some point you just gotta say this is too much for an average developer. Heck such a generic tool should be usable even by substandard developers.
My man.
> Kill the language and replace it with configuration
No. Hard no. Please don't tell me you are going to kill a fine (even though awkward) configuration language and replace it with (potentially text-templated) yaml.
I think I would rather replace it with a spec for derivation files implementable in any language that existing build systems can hook into and use as outputs.
Trying to package software with dependencies that don't exist in nixpkgs is painful despite the tooling existing to build and install them.I really like Nix package management. I really hate Nix configuration management. I already know how to configure everything. I don't want to have to figure out whatever abstracted config options some random package maintainer decided on.
I feel that. This is one place where the "nix is everything, everything is nix" mentality hurts the project. NixOS modules are where the abstract config option sauce lives. It isn't an inherent part of Nix.
As Nix (and NixOS) becomes more widely used, this is one place where we'll have to find a way to let users do what they know how, and stop getting in the way.
We have Nixstan on "Ops Team" who keeps pushing us to use it. We haven't seen need that much.
So can someone give me elevator pitch that if we are CRUD Web App, why Nix instead of Puppet/Ansible + Docker Containers?
Also, this from the blog article: "What if adopting Nix didn’t irritate your IT or security teams?" Too late, security team is already pissed. They did some scan, we pinned a package, it has 3 high severity and it needs to be updated tomorrow. So yea, we are just yoloing package updates, we don't have much of a choice.
Oh yea, we have some third party proprietary package we use. Support told us, Red Hat/Rocky/Ubuntu or we could kiss support goodbye. Any suggestions that doesn't involve shoehorning nix into Ubuntu which is like mud wrestling with a pig?
FWIW, the post looks more like a startup pitch from its founder than a more technical article.
My take as of now is that I like what Nix achieves, but I don't feel the complexity is worth it. Docker and similar container tech have issues, yes, but I'd have way way less trouble onboarding a dev on it than Nix.
I hope that changes in the future, though.
I mean, it sort of is, on the heals of two other announcements earlier this week:
* https://determinate.systems/posts/announcing-determinate-nix...
* https://determinate.systems/posts/flakehub-cache-and-private...
It's not going to be the future of anything if it doesn't get much better documentation.
Hear hear. It takes continuous effort not just on documenting, but also reducing the need for documentation by cutting interfaces and accidental complexity.
> To make a smooth path from “Nix could solve my dev, build, and configuration management problems” to “Nix is solving these problems” and in a way that doesn’t involve turning someone from a developer to “the Nix person.”
When do we get Nix easy enough for not just software engineers, but also scientists etc who need reliable reproducible systems for running simulations with zero hassle?
Hell yeah. Speaking my language! I don't know, but we need that!
Something I have never understood is why the hard-on with Nix, and Guix is not heard of even a tenth of the times. Is GPL really so repulsive to the masses? Or the libre kernel default?
I think guix was just late to the party and the extra steps to setup the nonguix for the non free software like steam is enough of a deterrent for users to go to nix instead.
I use guix myself and prefer its use of scheme. I don't mind having a little less guidance and "how-to" articles available if I'm trying something new because I'm comfortable reading its codebase.
The future is not what it used to be.
...and it never was.
Hey folks CEO of Determinate Systems, and the author of the blog post. I'd be glad to answer questions about the post and what we're doing!
I agree that Nix is the right idea, but I'm hesitant to adopt it right now because (i) rough edges like poor documentation and inconsistent interfaces make it feel immature, (ii) things are moving very fast with experimental stuff like flakes, which means it will take a while before Nix starts to stabilize, and (iii) recent community forks like Lix might create a fragmented ecosystem in the long run.
What are your thoughts on there concerns?
As a response to (ii), I assure you that things are most certainly not moving very fast with experimental stuff like flakes. Flakes were first released as "experimental" almost 3 years ago and have been stuck in feature purgatory ever since.
To be blunt, this is driven by the rejection of flakes by a significant group of the contributor base, despite it being much more adopted by the user base at large.
Even as someone who does think Flakes are better than the prior solutions, I'm increasingly of the opinion that Flakes would be better moved to a layer outside the core Nix project - advancing them within core Nix at this stage seems pretty impossible with many within the project opposed to their existence. I think if Flakes were an alternative project at the same level as something like Niv, a lot of the holy warring would get out of the way.
1. Those who wish to improve them could do so without the discussion being deadlocked by "hey, we haven't yet agreed these should be stable"
2. Those who don't want to paint them as the path forward for fear of precluding a better option, now don't have to.
I think those are fair perceptions and concerns.
Regarding experimental features like flakes: the reality is they're incredibly stable. I've written about this before: https://determinate.systems/posts/experimental-does-not-mean.... They haven't realistically changed in years, because they work so well. The experimental label is practically FUD at this point.
If the Nix team were to change flakes in a breaking way, it would be stunning neglect for the vast, vast percentage of the ecosystem that has already adopted them. Our data shows that of all the (OSS) repositories created every day, almost 90% of them start with a flake.nix. Of all of those projects, less than 20% use the legacy file formats, and most of those are using the flake-compat library.
On documentation and interfaces, I agree, and we and the greater community are working hard to on that problem. I'll take time, but it is decidedly better than it was a few short years ago.
And on community fragmentation, I just don't see it becoming a problem. The core Nix ecosystem is so large and diverse, I don't see meaningful fragmentation coming out of this.
> Our data shows that of all the (OSS) repositories created every day, almost 90% of them start with a flake.nix
90% of OSS repositories that use Nix I suppose?
Of course :).
I am a Windows user. The default nix implementation does not support Windows.
How can the future of software leave out one of the largest platforms on the planet?
Because the future of software isn't on Windows. Even Microsoft realizes that with MSSQL moving to Linux (and dying), .Net recommended on Linux and internally, vast majority of workloads that can run on Linux are doing so. Apparently, a ton of Office Teams architecture is Linux.
(Thanks for all your work on rust)
There is some work to get nix to work with Windows, this is mostly being done by john ericson.
However, the real issue is that nixpkgs (the repository containing all nix expressions) heavily assume unix paradigms.
There could be a "nix-windows repository" in the medium to far future, but it will likely be very divergent from the current nix+nixpkgs story of today.
Hi Steve!
Well. The future isn't evenly distributed yet :). There is work in flight to make Nix support Windows. Also, and I know this doesn't count, but it works great in WSL today.
Cool! I'm glad somebody is working on this.
What's your business model?
A FlakeHub organization with private flakes and cache is $20/user/month, plus at-cost storage and bandwidth. Members of that organization get automatic access to the private flakes and read access to the cache. In the future, we'll be opening up the policy engine to make it more flexible.
What about immutable systems like Fedora Atomic?
They're great! But also still miss fundamental pieces that Nix gets right. Especially the way the build and dependency graph goes right to the root of every package, and comes together to completely describe the system you're running today.
Is there a good book that describes everything we need to know?
https://nix.dev/ is pretty good for getting started these days.
https://nixos-and-flakes.thiscute.world/ is also an excellent resource.
Whew. "Everything" is a tough one, today.
1. I know there is an upcoming book, NixOS in Production. There is a lot of great info in there!
2. Have you seen https://zero-to-nix.com/?
Nix is the future gets another meaning if you know that nix in German means nothing.
Similarly in English. I think "nix", like "git", is a self-deprecating name. It's a play on both "nix" -- to cancel or to not exist, and "nix" as the suffix for Li- and U-.
It also means nothing in English, though that's somewhat obscure from my perspective. (Looking it up, it sounds like English borrowed it from German a while back.)
In English I think it's most often used as a verb that means basically to cancel. Like, "We're running out of time, we should nix feature X."
Eelco's typical online handle is "niksnut", which obviously means "nix nut" but also "good for nothing" :).
"Nichtsnutz" in german.
[dead]