Hacker News new | ask | show | jobs
by darkwater 1903 days ago
So you just shifted your dependency from Docker to Nix. It might be more fun and an intetesting learning experience but also it's more complicated (or at least it's not that widely used like Docker is)
3 comments

> It might be more fun and an intetesting learning experience but also it's more complicated

I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close.

> at least it's not that widely used like Docker is

"Which has more users" would not enter the top ten reasons I'd choose between tools like this.

I'm a major user of both and I can definitely say that Dockers basics are easier to learn and teach than Nixs basics. Maybe it has to do with the simple nature of the Dockerfile with just lines of commands, compared to Nix where you first need to learn the Nix language, then the idioms, then the package manager and now you can understand the OS. There is a couple of layers before things start making sense. While a Dockerfile is almost like a line-by-line shellscript.

At least that's my experience. Although I do prefer Nix over Docker any day, I'd definitely say the learning curve is steeper with Nix, but it's so worth it long-term.

>"Which has more users" would not enter the top ten reasons I'd choose between tools like this.

Size of the community, especially if its quality, means you just increased your surface area at getting help for issues you encounter. Which is a very non-trivial concern in a work environment.

> "Which has more users" would not enter the top ten reasons I'd choose between tools like this.

Why not? A big community means that you don't have to solve problems on your own, because someone else has probably solved the same problem before you.

If anything, it should be the <<first>> factor when making these decisions.

> I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close.

Well for starter Nix has a wider syntax because it covers much more than Docker + docker-compose. Which it's perfectly fine because they are two different tools that intersects in few use cases.

Syntax to install a few packages:

environment.systemPackages = with pkgs; [ wget vim nano zsh file ];

Including trailing semicolon. Dockerfile on alpine:

RUN apk add vim nano zsh file

I mean, maybe I'm too used to the latter but I really struggle to find the former simpler.

It means the ecosystem for Docker is more robust than for a Nix, which is patently true (see my comment here: https://news.ycombinator.com/item?id=26689378). I want to like Nix (and indeed I use it for some things), but it’s wildly immature, and maturity is a fine reason to choose one tool over another.

Also “imagine thinking...” is just vapid snark. If you must snark, at least make it substantial.

Yes, learning nix is definitely an investment, but it's more powerful than docker, allowing you to create your entire setup, including drivers, desktop environment, and any userspace apps you might need, all declarative, and contained in a config file (or several if you prefer)
> So you just shifted your dependency from Docker to Nix

OTOH you don't have to write all this boilerplate code that's suggested in the article and your Nix environment is truly reproducible, whereas rebuilding a Docker image might not reproduce it faithfully. (Try running `apt-get install` in a Ubuntu container without running `apt-get update` first.) On top of that, if you've ever had to use more than two languages (+ toolchains) inside a single project, maybe even on multiple architectures[0], you'll appreciate Nix taking care of the entire bootstrap procedure.

[0]: Lots of dependencies that are easy to install on x86 need to be installed/compiled by hand on arm64.