back
1 comments
I don’t really get it — my low resolution understanding is that Nix gives you the ability to define your Unix environment itself with definition files, similar to how Docker gives you the ability to define a container abstraction with Dockerfiles.

So if your whole machine’s environment is already specified, why do you need to add Docker as another layer of abstraction? Is it simply to deal with needing to run multiple apps on the same underlying machine (defined by Nix) with possibly conflicting dependencies (those would be managed by Docker)?

With nix, the whole dependency hell problem is solved, so you will not get conflicting dependencies anymore (other than perhaps bugs). You could install the same program twice with the exact same version of libc compiled by gcc and clang for example and it would still not get into each other’s way.

Docker on the other hand doesn’t solve this problem itself - docker images can be built declaratively (eg. with nix itself), but it is more about managing the running of services with possibly different environments. A typical dockerfile will not be identical at all between two separate creations (most of the time it just installs programs from a repository without any versioning other than perhaps the distro’s major version)

The fact that we as in software developers use it for dev environment is just the unfortunate way it is.

You can get the reproducibility resolved. But when I tried nix I didn’t found a way to save the source code easily in my project. Similar to the vendor directory in Go there should be a way to backup the source since the source can go away any time.
What do you mean? Just use a git repository as a source, but you may as well create a hashed folder containing your source files, but that is not the primary function of nix.
I mean so I can reproduce it in 10+ years where many git repos don’t exist anymore. Go can keep checksumed copies of any code it uses to compile. I’d like to see this in Nix as well.
One use case I see is if you're using Nix for all your local development, but Docker in production (because it's the easiest these days: package an image, give it to ECS/Fargate or equivalent and it's good to go).

You're not using Docker in development because of the sync issues on Mac between the host and the containers, but ideally you still want as much as possible the development and production environment parity (same versions of dependencies, etc). You can build your Docker images with Nix to ensure the dependencies versions you're developing with will be the same in prod.