Live data from Hacker News

Will Nix Overtake Docker?

blog.replit.com

71–80 of 259 posts

Re: Will Nix Overtake Docker?

#71

I think people are missing the forest for the trees with this. In my view, the reason Docker has all the hype is because I can look at a Dockerfile, and know what's up. In seconds. Sometimes in milliseconds. It's a user experience thing. Yes, Nix is better for 'technical people that spent the time learning the tool', but Dockerfiles rely almost entirely on existing System knowledge. Yes, Nix is 'better', but the fact…

Author here. As with most things, its all about the trade-offs. Docker has certainly proved itself and that approach has worked on a massive scale. However, its not a silver bullet. For us at Replit, our Docker approach was causing issues: our base image was large and unmaintainable and we had almost no way of knowing what changed between subsequent builds of the base image. We've been able to utilize Nix to address…

Those sound like issues with your Docker usage - there are options to keep base image quite streamlined (e.g. alpine or distroless images).

Re: Will Nix Overtake Docker?

#73
post #20

IMO initial value of docker for local development is enabling me to run two copies of postgres without them shitting on each other. I get that nix is supposed to be hermetic, but does it enable two of something? nix being really good at package management is something docker needs to imitate -- out of order apt-get without requiring a re-downloading all the packages, for example, seems like it would shrink most cloud…

Nix supports this quite well. https://nixos.org/manual/nix/stable/#multiple-versions The Nix and container mindset are very similar in that they refer to all of their dependencies, including down to glibc.

Does Nix understand network namespacing? Or would 2 postgres instances clash over tcp listen ports?

I get you could configure different ports, or virtual interfaces, but it sounds like either of those would be outside of the nix tooling.

Re: Will Nix Overtake Docker?

#75

Earlier quoted context omitted.

Author here. As with most things, its all about the trade-offs. Docker has certainly proved itself and that approach has worked on a massive scale. However, its not a silver bullet. For us at Replit, our Docker approach was causing issues: our base image was large and unmaintainable and we had almost no way of knowing what changed between subsequent builds of the base image. We've been able to utilize Nix to address…

Those sound like issues with your Docker usage - there are options to keep base image quite streamlined (e.g. alpine or distroless images).

For context, I'm referencing our (legacy) base image for projects on Replit: Polygott (https://github.com/replit/polygott/).

The image contains dependencies needed for 50+ languages. This means repls by default are packed with lots of commonly used tools. However, the image is massive, takes a long time to build, and is difficult to deploy.

Unfortunately, slimming the image down is not really an option: people rely on all the tools we provide out of the box.

Re: Will Nix Overtake Docker?

#76
post #29

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get…

This mirrors my experience as a developer in an org that used Nix. If you want the dev team to have a strong dependency on the devops team for every little (often unpredictable) aspect of their workflow, Nix is the tool for the job.

Don’t get me wrong, I’m completely bought in on the vision of reproducible builds but there’s a long ways to go before it’s usable in real organizations. I’ve heard that some orgs manage it, but I really have no idea how. Maybe some critical mass of people who already know and love Nix (and implicitly packaging obscure dependencies)?

Re: Will Nix Overtake Docker?

#77
post #34

What's the easiest way to deploy a docker container to a VM? Preferably without ten layers of cloud provider interconnected services or expensive and complex kubernetes layers? I just want to send a container and get back an IP address I can send some traffic to the exposed port(s).

Dokku. I'm a DevOps noob, just recently picked up Docker, and had such an easy time with Dokku, I decided on it for my current deploy process. Once you setup a few Dokku commands on the server, you can git commit, git push to the dokku remote and it runs your docker container automagically.

Re: Will Nix Overtake Docker?

#78
post #2

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 i…

Yes, and Nix can still lose on maintainability in the long run, considering it is more difficult to onboard new devs with it. They have to learn the Nix expression language and write custom bindings for much software instead of calling the native package manager inside Docker.

Re: Will Nix Overtake Docker?

#79
post #29

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get…

>Build times in Haskell were bad enough this one's very true. Every time I try to build something in Haskell on my laptop it feels like we're moving closer to the heat death of the universe. Is there some good read on how/why Haskell compilation times are so long compared to some other languages?

If you're compiling a project for the first time it's probably pulling in a ton of libraries and compiling them all from scratch. But let's be real here - we're talking maybe 3-5 minutes for the first build of a huge Haskell codebase, one or two orders of magnitude faster on second build.

It seems comparable to what I've noticed with Rust or C, and pretty fast compared to some medium/large C++ codebases I've built.

I'm not really sure what workflows people are using where this is a problem, so this may be less of a pain point for me than it is for you. Personally I build Haskell projects once to pull in the dependencies, then use ghcid to get ~instantaneous typechecking on changes I make to the codebase.

Post reply on HN