As TFA itself answers, "no". But I can give a different reason: nix is too much of a barrier of entry, relative to Docker.
Docker might not be simple; there's a lot of moving parts to manage, some hidden gotchas, and networks are a mess. But it's comparatively easy, and once you bake an image, it's pretty simple. Dockerfiles are basically just sh. Package managers are the usual suspects. Images are easy to distribute. It's very familiar.
Nix is not easy. It's a new syntax to learn, it's a new way of building, it's an entirely new way of thinking about the problem. But in the end, it does simplify packaging in the Rich Hickey sense of the easy/simple dichotomy. No braiding of packages and shared libs. But using Nix is not so simple. There's all kinds of bindings and bodges and bespoke shims to make it all work.
History tends to show that easy+non-simple things beat out simple+non-easy things (devs are lazy). Easy-kinda-simple vs non-easy-kinda-simple-but-long-term-gains? No contest in my opinion.
I think Nix is a beautiful idea but it's an uphill battle.
One thing I like with Nix is that it can build containers, so it's totally compatible with deployment systems that require containers. I don't mean using Nix commands in a Dockerfile, I mean having a Nix derivation that produces a container.
I've been writing normal Dockerfiles at work recently and the whole toolchain is annoying on multiple fronts; I'd love to jump to Nix instead, except it's really hard to convince other people to learn non-trivial technology that's off the beaten path :(.
Docker and Nix are mostly orthogonal technologies though. Nix is an excellent build tool while Docker is useful as an universal software distribution format. They're really useful together because Nix is actually good at creating compact Docker images. But of course, if you don't have to worry much about distribution, it would be much nicer to stick with Nix as you've mentioned.
But also Nix solves more problems than Docker. For example if you need to use different versions of software for different projects. Nix lets you pick and choose the software that is visible in your current environment without having to build a new Docker image for every combination, which leads to a combinatorial explosion of images and is not practical.
But I also agree with all the flaws of Nix people are pointing out here.
No, it definitely (but unfortunately) will not. Nix does everything docker does better than docker does, except most crucially, integrate with non nix tooling.
Nix vs Docker is like Rust vs JavaScript - you can point out every reason js is terrible and rust is better, but for the common developer looking to get things done, they’ll often gravitate to the tool that gets them the biggest impact with the least upfront investment, even if that tool ends up causing major predicable headaches in the future.
Sounds like it, I don't know enough about Nix to know if it addresses the same scope of need that docker does, hopefully someone who is savvy can chime in :)
It seems that Docker is more concerned with containment and Nix with packages. I would love to be able to use Nix to define my project+dependencies and Docker to run it.
I'd be surprised if someone hasn't already made a baseline NixOS docker image to build off of.
I came to say the same. While they are not exactly competing solutions, for the most typical use-case (i.e. packaging, configuring and deploying software without dependency hells) Nix is simply so much better and less wasteful than docker. Pure bliss.
Absolutely! From my point-of-view, Nix is complementary to Docker. Nix is a deterministic replacement for the apt-get commands used in the parent post.
Nix can provision containers, VMs, bare metal. It is much more capable than Docker because it composes, and doesn't use opaque disk images as the basis for everything. Nix provides much better reproducibility.
Nix will not overtake Docker because
1. The overlap is not that big
2. Nix has usability issues
That being said Nix even with its usability issues works better for reproducible development environments than anything else (including Docker) ATM.
Therefore in my view either Nix or something very similar will be the solution for this and replace Docker (some people run builds using Docker containers) for this use case.
I like nix because it seems like an alternative to docker. Yet. Im never going to use it, because it has complexity and i dont understand why. Which is why i dont use docker nor nix. I can work with both, i just dont want to waste my time on them unless i have no other option.
On the face of it not, no. But when you consider the immense power and versatility of it (you can do anything from setting up simple virtual envs to automatically deploying a multi-container setup on AWS), it starts to become a lot simpler than the sum of all the other tools that it replaces. Nix is a single principled idea, but can be used in so many different contexts.
Coming from docker before nix, I think nix is a better version of docker for some use-cases. If the ecosystem is supported then I much prefer nix for speed (both runtime and development speed)
Docker might not be simple; there's a lot of moving parts to manage, some hidden gotchas, and networks are a mess. But it's comparatively easy, and once you bake an image, it's pretty simple. Dockerfiles are basically just sh. Package managers are the usual suspects. Images are easy to distribute. It's very familiar.
Nix is not easy. It's a new syntax to learn, it's a new way of building, it's an entirely new way of thinking about the problem. But in the end, it does simplify packaging in the Rich Hickey sense of the easy/simple dichotomy. No braiding of packages and shared libs. But using Nix is not so simple. There's all kinds of bindings and bodges and bespoke shims to make it all work.
History tends to show that easy+non-simple things beat out simple+non-easy things (devs are lazy). Easy-kinda-simple vs non-easy-kinda-simple-but-long-term-gains? No contest in my opinion.
I think Nix is a beautiful idea but it's an uphill battle.
reply