The future of software is Nix in the same sense that the future of software was Bitkeeper.<p>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.<p>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.<p>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).<p>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.
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.
> 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.”<p>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?
FWIW, the post looks more like a startup pitch from its founder than a more technical article.<p>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.<p>I hope that changes in the future, though.
We have Nixstan on "Ops Team" who keeps pushing us to use it. We haven't seen need that much.<p>So can someone give me elevator pitch that if we are CRUD Web App, why Nix instead of Puppet/Ansible + Docker Containers?<p>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.<p>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?
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?