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.
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.
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.
> 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.
I posted some information and metrics about that on Discourse:
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.
What are your thoughts on there concerns?