6 ms·

No, it definitely (but unfortunately) will not. Nix does everything docker does better than docker does, except most crucially, integrate with non nix tooling.

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 investment, even if that tool ends up causing major predicable headaches in the future.

abathur 5y ago
I like to compare Nix to ice-nine from Cat's Cradle, in that it tends towards restructuring whatever it comes into contact with.
- doublepg23 5y ago
  Funny you mention that. Guix which is a fork (of sorts) of Nix is written in Guile Scheme which uses ice-9 as it's namespace in a lot of places. https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00046.html https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00...
  - rekado 5y ago
    This gets repeated a lot, but Guix really is not a fork of Nix. Not by any definition of "fork". Also not "a fork of sorts". The term "fork" only applies to one executable: "guix-daemon", which is a literal fork of "nix-daemon". They have, of course, diverged a lot, but this (and nothing else) is truly a fork. Aside from this one executable there is no relationship between the two projects. The daemon takes .drv files that list what preconditions a build has (= other .drv files), what build script to run (= a generated Guile script), and what outputs will exist when the .drv file has been processed. It processes these .drv files in an isolated environment (chroot + namespaces) where only the inputs mentioned in the .drv file are made available. The drv files are not shared among the projects; they are not generated in even superficially similar ways. Guix is not a fork of Nix. "guix-daemon" is a fork of "nix-daemon". Both are implementations of the same idea: functional package management.
    - ShamelessC 5y ago
      This fits my definition of a fork (of sorts). Thanks for the nuance though.
    - doublepg23 5y ago
      I love reading your blogs on Guix, I'll keep that in mind for future reference sorry for the libel ;)
xxpor 5y ago
My favorite feature of NixOS so far though is the ease of creating containers via the configuration.nix file. There's a few services I run that don't have nix packages, but do have containers. It's essentially like writing a docker compose file, but instead of YAML, you use Nix and all of the niceties that come with it. Seems like the best of both worlds (as someone who isn't themselves creating containers).
3np 5y ago
There’s just too many edge cases and system/language oddities that make me continuously reach for Docker as default, even after 4 years of NixOS as daily driver.
lolpython 5y ago
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.
- CameronNemo 5y ago
  I don't understand how these are comparable. I also don't understand what you mean by "bindings". Do you mean writing nix derivations for new packages? I would much rather do that than fiddle with Debian packaging. Or do you mean writing nix modules to configure a service? There are certainly some (IMO) over engineered nixos modules, but there are also some dead simple ones.
  - lolpython 5y ago
    > I don't understand how these are comparable They fulfill similar business functions - allowing you to run the same code on a bunch of dev machines and on prod (modulo modifications for e.g. database storage in Docker's case). Nix people get hung up on the fact that Docker runs containers, but it doesn't really matter that much. Often Docker is the shortest path to getting software running on multiple machines reproducibly. > I also don't understand what you mean by "bindings" I am referring to derivations and modules. Both are glue that you have to write for existing software that is already packaged. With Docker you leverage the existing packaging ecosystem like pip or apt. The packages are already written for you, and you can follow the installation instructions from a project repository and they translate seamlessly into Docker. For example with ML & Python - If you want PyTorch with CUDA support, you can follow the official documentation [0] and basically copy and paste the installation instructions to a Dockerfile RUN statements. If anything breaks you can file an issue on the PyTorch issue tracker which has a wide audience. With Nix you have to write glue on top of the installation yourself, or a maintainer does it with a much smaller code review and support audience. Sometimes the audience is just the author, given that Nix project people commit directly to master frequently and do self-merges of PRs [1]. And there are other hurdles like compiling Python C extensions, which are pervasive. Another example is with software systems, I guess this would be a Nix module. Here's GitLab: [2] where it was really difficult to translate the services into Nix. But a lot of company internal services can look like GitLab with a mix-mash of odd dependencies and languages. And writing a Dockerfile for this is much easier than Nix, since you can copy from the existing README specifying the Debian or language-specific dependencies. (edit: and if there are conflicts between dependencies of the services they can go into different containers. Getting the benefit of Nix - reproducibility - without the extra effort.) [0]: https://pytorch.org/get-started/locally/ https://pytorch.org/get-started/locally/ [1]: https://discourse.nixos.org/t/proposal-require-pr-authors-to-review-other-prs/16242 https://discourse.nixos.org/t/proposal-require-pr-authors-to... [2]: https://news.ycombinator.com/item?id=14717852 https://news.ycombinator.com/item?id=14717852

abathur 5y ago

I like to compare Nix to ice-nine from Cat's Cradle, in that it tends towards restructuring whatever it comes into contact with.

doublepg23 5y ago
Funny you mention that. Guix which is a fork (of sorts) of Nix is written in Guile Scheme which uses ice-9 as it's namespace in a lot of places. https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00046.html https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00...
- rekado 5y ago
  This gets repeated a lot, but Guix really is not a fork of Nix. Not by any definition of "fork". Also not "a fork of sorts". The term "fork" only applies to one executable: "guix-daemon", which is a literal fork of "nix-daemon". They have, of course, diverged a lot, but this (and nothing else) is truly a fork. Aside from this one executable there is no relationship between the two projects. The daemon takes .drv files that list what preconditions a build has (= other .drv files), what build script to run (= a generated Guile script), and what outputs will exist when the .drv file has been processed. It processes these .drv files in an isolated environment (chroot + namespaces) where only the inputs mentioned in the .drv file are made available. The drv files are not shared among the projects; they are not generated in even superficially similar ways. Guix is not a fork of Nix. "guix-daemon" is a fork of "nix-daemon". Both are implementations of the same idea: functional package management.
  - ShamelessC 5y ago
    This fits my definition of a fork (of sorts). Thanks for the nuance though.
  - doublepg23 5y ago
    I love reading your blogs on Guix, I'll keep that in mind for future reference sorry for the libel ;)

xxpor 5y ago

My favorite feature of NixOS so far though is the ease of creating containers via the configuration.nix file. There's a few services I run that don't have nix packages, but do have containers. It's essentially like writing a docker compose file, but instead of YAML, you use Nix and all of the niceties that come with it. Seems like the best of both worlds (as someone who isn't themselves creating containers).

3np 5y ago

There’s just too many edge cases and system/language oddities that make me continuously reach for Docker as default, even after 4 years of NixOS as daily driver.

lolpython 5y ago

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.

CameronNemo 5y ago
I don't understand how these are comparable. I also don't understand what you mean by "bindings". Do you mean writing nix derivations for new packages? I would much rather do that than fiddle with Debian packaging. Or do you mean writing nix modules to configure a service? There are certainly some (IMO) over engineered nixos modules, but there are also some dead simple ones.
- lolpython 5y ago
  > I don't understand how these are comparable They fulfill similar business functions - allowing you to run the same code on a bunch of dev machines and on prod (modulo modifications for e.g. database storage in Docker's case). Nix people get hung up on the fact that Docker runs containers, but it doesn't really matter that much. Often Docker is the shortest path to getting software running on multiple machines reproducibly. > I also don't understand what you mean by "bindings" I am referring to derivations and modules. Both are glue that you have to write for existing software that is already packaged. With Docker you leverage the existing packaging ecosystem like pip or apt. The packages are already written for you, and you can follow the installation instructions from a project repository and they translate seamlessly into Docker. For example with ML & Python - If you want PyTorch with CUDA support, you can follow the official documentation [0] and basically copy and paste the installation instructions to a Dockerfile RUN statements. If anything breaks you can file an issue on the PyTorch issue tracker which has a wide audience. With Nix you have to write glue on top of the installation yourself, or a maintainer does it with a much smaller code review and support audience. Sometimes the audience is just the author, given that Nix project people commit directly to master frequently and do self-merges of PRs [1]. And there are other hurdles like compiling Python C extensions, which are pervasive. Another example is with software systems, I guess this would be a Nix module. Here's GitLab: [2] where it was really difficult to translate the services into Nix. But a lot of company internal services can look like GitLab with a mix-mash of odd dependencies and languages. And writing a Dockerfile for this is much easier than Nix, since you can copy from the existing README specifying the Debian or language-specific dependencies. (edit: and if there are conflicts between dependencies of the services they can go into different containers. Getting the benefit of Nix - reproducibility - without the extra effort.) [0]: https://pytorch.org/get-started/locally/ https://pytorch.org/get-started/locally/ [1]: https://discourse.nixos.org/t/proposal-require-pr-authors-to-review-other-prs/16242 https://discourse.nixos.org/t/proposal-require-pr-authors-to... [2]: https://news.ycombinator.com/item?id=14717852 https://news.ycombinator.com/item?id=14717852