The future of software is Nix
determinate.systems
determinate.systems
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.
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 :).
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....
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.
make derivation
python -m build derivation
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.
I remember being enamored by Haskell in college and I asked my professor why pure functional languages aren't more popular. His answer really stuck with me. He said: because reality is stateful.
Reality is stateful. As a consequence, declarative configuration leaks like a sieve, and leaky abstractions suck. When you think about it, declarative configuration is just a DSL for implementing idempotent deployment flow, and idempotent deployment flows in general are quite successful (e.g., Docker, Flatpak, Ansible), and so declarative configuration tends to work okay for restricted subsets of those domains.
Outside Nix, there's Brioche (my project!), and there's also Vorpal and Tangram, all of which are "Nix-like" but are from-scratch projects instead of using any Nix tooling
So I definitely agree that Nix as an _idea_ is right, and I definitely also agree that NixLang is a blocker for mass adoption. Personally though, I think if you dig deeper, there are other places that could use improvement beyond just the language itself (but nothing that would necessarily be a show-stopper for adoption IMO). But that's why my project is a "Nix-like"-- there are things that I think Nix could / should do, but which aren't really compatible with the way Nix itself works. One example: Brioche works without having a global store path-- it's per-user instead so that it can be installed rootlessly-- which doesn't really map well to how Nix itself handles store paths and dependencies
So point is, I agree Nix is the right model, but I think the _real_ gold lies outside Nix itself (...with the side note that I'm obviously biased!)
What we probably need, long term, is a content addressable store, local first, secure, and freely shareable. Layering this on top of POSIX filesystems feels awkward and difficult to trust. But this is the fundamental building block of Nix-like systems and would make the move from rootless to system-wide a mostly trivial exercise.
Have you tried using it in user space?
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.
I wouldn't be mad if opening the system preferences and setting my timezone also updated my timezone in Nix. I am mad that I can't change my timezone when I travel, because the GUI picker doesn't know that Nix has taken ownership, so only changes in Nix take effect.
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?
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.
* https://determinate.systems/posts/announcing-determinate-nix...
* https://determinate.systems/posts/flakehub-cache-and-private...
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?
For better or worse, Nix forces you to work out the exact dependency tree of your entire system. It can be a pain but once you have it, if one part of that tree changes, nix can rebuild only and exactly the parts of the system that depend on it. That goes all the way through from packages and libraries to systemd services and application config files. That happens safely, reliably, is extremely cacheable, and is done in a way that can actually be perfectly reverted to a previous version. You can build docker images with nix and the result is very small minimal images (it's effectively a `FROM scratch` every time but with a potentially even better layer structure that again can be more cacheable than a typical Dockerfile setup).
From a security perspective, Nix can be a huge win since it gives you such precise control over what's installed on your system and makes it simple to track, every part of it checks cryptographic hashes, etc. But yeah, most security teams don't know what to do with it yet and probably don't have the tools to deal with it yet.
How can the future of software leave out one of the largest platforms on the planet?
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.
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.
What are your thoughts on there 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.
90% of OSS repositories that use Nix I suppose?
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 posted some information and metrics about that on Discourse:
https://discourse.nixos.org/t/announcing-determinate-nix/547...
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.
FWIW Nix does not allow unfree packages by default or, at least, that's what having to add a package to allowUnfreePredicate makes it feel like.
What's your business model?
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/?
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."