Hacker News Reader

Comment by ilovecaching | Hacker News Reader

My friend at work will never stop talking about Nix and NixOS. The entire world would be a better place if we all just stopped using Docker and Chef and switched to Nix. Every package you could want is in Nix, and it's all on Github. Anything your tool can do, Nix can do it better, except it's congruent instead of convergent.

My rebuttal has always been that NixOS has been out for awhile and we still haven't seen mainstream adoption despite how supposedly great it is. I don't know of any high profile companies using Nix. It appears to be as hobbyist as Haskell.

View on HN

> My rebuttal has always been that NixOS has been out for awhile and we still haven't seen mainstream adoption despite how supposedly great it is.

Adoption does not and has never followed from technical superiority. The tech industry today would be almost unrecognizable if it did.

People move slowly. Degree of adoption isn't a good proxy for value.

> Every package you could want is in Nix

Is it though? I deploy applications (a mix of Python, node and C++) for which the vast majority of the dependencies are missing, misconfigured or out of date in nixpkg. Sure I could volunteer to maintain dozens of nix packages but the fact remains that forcing all of your deps through a single packaging system is risky. NixOS in particular encourages you to buy into the ecosystem 100% or not at all. That's a big ask, even for small organizations.

Compare that to Docker where your can build your app on top of any base image and use/develop/deploy that artifact from many different environments. I can distribute and build my dependencies in whatever way is appropriate for my application, my team and collaborators can hack on that image from their chosen OS, and the application can be built deterministically and deployed anywhere that can run a docker daemon. No lock-in required: the dev host OS, deployed host OS and container OS are managed independently. Docker is not as "pure" as NixOS but it works under the real-world constraints of heterogeneous environments.

Of course everything would be better if we could all agree on one package manager and one OS and one programming language for that matter. But we can't, so the clear winner is the technology that can leverage this homogeneity into a uniform build artifact (containers). Technologies that require package-level homogeneity across an organization in order to succeed are fighting an uphill battle.

The claimed advantages of Docker over Nix here don't line up with the reality I've seen after years of experience with Docker and Nix, particularly with how they relate to services that wind up deployed with Kubernetes.

I can do almost all the same things that you do with Docker, with Nix. Why would I ever need a different base image if I'm composing my image with Nix? Nix+Docker is the best of both worlds and there's really absolutely no reason to not pair them together.

Besides if for some reason, you can't package something in Nix, or refuse to buy into the `nixpkgs` ecosystem, you can still build a reproducible Docker image with whatever base layer you want (`alpine`, `redis`, whatever), with Nix, and benefit from all of the benefits mentioned in this post and others in this thread.

Deployment time, yeah, they're all opaque containers and they can be running whoknowswhat. But for day to day development, Nix absolutely beats Docker. I've spent way too much of my life rebuilding binaries and container images that already exist. Wasted too much of my life on containers and binaries of unknown, unreproducible origins. None of those things are concerns when you're building your container images with Nix. They're not even a thought I have any more.

It's slowly moving out of the hobbyist realm though - there has been a consistent output of "stable" releases with very little problems upgrading.

One reason it hasn't gotten much traction yet might be because the perceived benefit is too low to convert existing systems: You can upgrade in place, downgrade, manage a whole fleet easily etc, but the people with these problems already have (bad) solutions for those in place.

So there's a lot of inertia, and uptake has to come from new installations.

I too managed a Chef based infrastructure, and it was terrible. I don't like it when simple deploys break a production system because of a missing comma in some config file. With NixOS/NixOps, many issues that Chef has just don't exist.

Your friend is correct. Do you sincerely think everything that is more famous is better?

Generally yes. Better technologically is usually not outweighed by having to learn and support something that has a smaller community base, and there's usually less people contributing to the ecosystem.

Python many not be the best language, but it has a package for everything and it's easy to find answers when you get stuck.

>My rebuttal has always been that NixOS has been out for awhile and we still haven't seen mainstream adoption despite how supposedly great it is. I don't know of any high profile companies using Nix. It appears to be as hobbyist as Haskell.

If it's anything like Haskell, then here's how this goes: there are going to be some problems for which NixOS is not only the best solution but the only reasonably viable solution. For all other problems, it will be inconvenient.

I think it's well known, that Nix has a lot of implementation related problems that prevent its mass adoption. They are fixable, but only by different people and in a different package manager. By those, who care about UX and can understand that learning some weird functional programming language and its ecosystem to do basic package management is not ok, but who can still appreciate Nix's ideas.

That sounds right to me. I could see how fundamentally it would be great, but I think it's as you said.

Reply on news.ycombinator.com