Hacker News new | ask | show | jobs
by ruuda 1310 days ago
One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. With a Nix-based development environment, it can add/override the tools you need, but you get to keep your shell customizations, editor config, etc.

Also reproducibility; it can be achieved with containers if you save the artifact (the container image), but that's not what people do in practice, they save only the recipe (the Dockerfile), and if you execute it tomorrow, it will produce a different result than today, and it will likely not even run one year from now (due to e.g. third-party apt repos changing their url, signing keys expiring, curl|bash installers that are no longer hosted, etc.). With Nix, every run will produce the same results, and sources for everything packaged in Nixpkgs are saved by nixos.org.
2 comments
nordsieck 1310 days ago
> One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc.

Can't you just mount a volume from your host machine? Then you can use your regular editor, and just run commands from inside the container.

link
rgoulter 1310 days ago
While it is possible to work with containers to run programs with files on the host, it's just much more convenient to be able to run programs without dealing with mounting issues.
link
ruuda 1310 days ago
For an editor, maybe, for the files that you mount. But when e.g. a language server or IDE is involved, they need access to the tools that are now only inside the container. And then there's the shell itself, your shell history, etc.
link
moojd 1310 days ago
On Linux absolutely, the IO latency on MacOS with mounted volumes is atrocious. Using a nix environment also avoids the weird edge cases I tend to run into with volumes mounts and file ownership and such.
link
visarga 1310 days ago
> it will produce a different result than today, and it will likely not even run one year from now

Any way to hack this? Just pretend it's a different date, the pointers to the latest package will changed to reflect that.

Or somehow record the exact versions when you first build the container, and freeze that.

link
ruuda 1310 days ago
It's not just about system time, it's about unpinned dependencies on external things. E.g. if you run apt update, after a package is updated upstream, it may install a newer version.
link