[callahad]

Strictly compared to containers, the big advantages are reproducibility and lower overhead.

Overhead: Windows and macOS can't run Linux-based containers natively. Instead, there's always a full Linux virtual machine running in the background acting as an intermediary and host for your containers. Nix can conjure arbitrary native development environments on a per-command or per-terminal basis, giving you all the performance of directly running tools without the risk of clashing with systemwide software.

Reproducibility: Nix provides much stronger guarantees about the exact versions of software you're running. It effectively gives you a lockfile for your entire dependency chain, all the way down to libc. Containers tend to be more stateful: everyone on your team may be using the same Dockerfile, but if you build an image from it two weeks apart, you're probably going to get very different outputs due to things like your apt-get update step returning new versions of packages. This doesn't happen with Nix.

The beauty is that this isn't either/or; you can actually use Nix to generate OCI container images which are thus fully specified and repeatable.

[peterbecich]

Adding to this, my understanding is that Nix does not guarantee any Nix derivation/package will seamlessly run on Linux, Mac, and Windows. So in this one aspect it is less capable than Docker, i.m.h.o.

i.e. if a package depends on the systemd package https://search.nixos.org/packages?channel=unstable&show=syst... , Nix will not automatically find a replacement to run the package on Mac. But it may be possible to manually work around this with https://github.com/LnL7/nix-darwin

More on building Docker images with Nix: https://nix.dev/tutorials/building-and-running-docker-images

[pxc]

> Nix does not guarantee any Nix derivation/package will seamlessly run on Linux, Mac, and Windows. So in this one aspect it is less capable than Docker, i.m.h.o.

Nix runs on Windows exactly like Docker runs on Windows— only inside a Linux VM. If you ship a Linux VM on Mac or Windows like people usually do for Docker, you're free to run the Linux version of a Nix package on those platforms.

> i.e. if a package depends on the systemd package https://search.nixos.org/packages?channel=unstable&show=syst... , Nix will not automatically find a replacement to run the package on Mac. But it may be possible to manually work around this with https://github.com/LnL7/nix-darwin

Nix-Darwin doesn't do anything for packaging issues, it just offers an alternative module system for declaratively managing services and configurations in a NixOS-like way.

Docker containers also don't normally do any kind of service management, they're single-process images. They're not really comparable to orchestrated services managed by NixOS or Nix-Darwin modules. But if your concern is just shipping the same thing and you don't care about what's managing the services, a whole NixOS VM isn't any less efficient than some other VM in which you run `docker-compose` or Kubernetes.

That said, there are Nix-y ways to ship one or more supervised processes in a way that's portable across the platforms that Nix supports. One way is with a manually tailored supervisord config with a nix-shell or something like devenv.sh. Another strategy would be to leverage something an abstraction layer like this one: https://github.com/svanderburg/nix-processmgmt

[valcron1000]

AFAIK, Nix does not work natively on Windows (you need to go through WSL), so it's not better in that regard.

[callahad]

Ah, yes, you're correct. You can use Nix to cross-compile for Windows, but you're not going to run Nix itself there.

[airocker]

Would nix guarantee that all upstreams are available forever? Is nix planning to replace all upstreams? (PyPI, Conda, npm etc?) OR does it plan to keep a cache forever?

[callahad]

Not yet. There have been some efforts around adding IPFS support to Nix, as well as making its storage fully content addressable, which would allow for peer-to-peer archival and distribution of source. https://blog.ipfs.tech/2020-09-08-nix-ipfs-milestone-1/

Guix, a similar project to Nix, has been tackling this head on by automatically falling back to the Software Heritage archive when the original upstream is unavailable: https://guix.gnu.org/en/blog/2019/connecting-reproducible-de...

[Arcuru]

Nix doesn't keep a cache of the upstreams, though there are some projects planning to try to do that I think.

The build recipes pull from the original source and use a hash to ensure that the source artifacts don't change. Nix caching is usually done at the build output layer, e.g. the resulting binaries.

[airocker]

So it does plan to replace all up streams eventually including apt, npm, pypi, gem etc by providing the ability to build and configure all software? I am not understanding this, currently the original maintainers release on their own stores. the build and configure steps may change over time. Unless the original maintainers start building for nix, would not this be too hard to maintain?

[callahad]

> the build and configure steps may change over time. Unless the original maintainers start building for nix, would not this be too hard to maintain?

This is indeed very hard, but Nix's deep locking makes this a tractable problem: if a version of a package builds once, it will keep building for as long as the source code is available.

So in some ways, this Nix has an easier job compared to traditional distribution mechanisms. On the other hand, Nix can be sufficiently weird and unwieldy as to limit the number of potential contributors.

[airocker]

but new versions may need new steps to build?

[callahad]

Yes, at which point you'll have to update the build script... but until you do that, the current build script will still pull in the previous version of the software and all of its dependencies, including system-level ones, so you won't have incidental breakage from the surrounding environment changing out from under you.

This works going backwards, too. If you need an older version of some software, Nix can happily install it for you in a way that won't conflict with other software on your system. The only requirement is that you can still get the original sources and you can get a copy of the nixpkgs repo at the time the older version of that software was initially committed.