5 ms·

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be clean

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

rob_c 2y ago
It's basically, I refuse to learn how to containerize. Just learn, use, promote best practices and stop forking the ecosystem _even_ further... There, I got that off my chest.
- jvandreae 2y ago
  The problem with docker is less the containerization and more the half-baked build system.
- jjmarr 2y ago
  Well, yeah. Nix is attempting to be better than containerization. Saying "improvements aren't necessary because we already have 'good-enough' technology" is a meaningful argument when the improvements aren't significant. In my view, they are significant because Nix can be used to create a fully featured OS instead of just a VM.
  - pzmarzly 2y ago
    > they are significant because Nix can be used to create a fully featured OS instead of just a VM Look up Bootable Containers project by RedHat [0]. Fully featured OS built from a Containerfile, bootable on bare metal. I agree that Nix design is much better than Docker, and has a bunch of features that OCI ecosystem doesn't (e.g. remote builds[1], partial downloading of the build tree, non-linear build process[2], nix store import/export, overlays, I/O isolation, much better composability), but "creating OS instead of VM" [did you mean container?] is not one of them. [0] https://github.com/containers/bootc https://github.com/containers/bootc [1] You can use DOCKER_HOST, and I'm happy that this option is there, but Nix does it better. [2] Perhaps with BuildKit it's no longer true, I haven't checked what happens if you have multi-staged build with one stage depending on multiple previous ones (which are otherwise unconnected). I think Earthly can parallelize this scenario https://earthly.dev/ https://earthly.dev/
    - cpuguy83 2y ago
      Yes buildkit can do this. You can also use buildkit to create a bootable VM, just that nobody is doing it. You can use estargz to fetch just the pieces you need from a dependency rather than the entire depdency as well. Really all of the things you mentioned should be possible with buildkit, just that the focus of most things is Dockerfile which has much more limited functionality (though some of the things mentioned above still apply to Dockerfile).
- edude03 2y ago
  As a heavy container user myself - I've been using containers since I needed to build my own 3.x kernel to test them - docker doesn't solve the reproducibility problem nix solves - IE, I can make a Dockerfile that does `RUN curl foo.com/install.sh` and who knows if that'll work ever again. Nix on the other hand doesn't allow you to do IO during builds[^0] only describe the effect of doing the IO. [0]: Though apparently darwin (mac) doesn't support sandboxing by default, so you can bypass that but anyway
  - XorNot 2y ago
    You can just store the actual container though. Which will reproduce the environment exactly, it's just not a guidebook on how it was built. The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact reproduction: what we want is the ability to record what was important and effect upgrades.
    - edude03 2y ago
      I'm not talking about a bit perfect reproduction though, just being able to understand dependencies. Take for example a simple Dockerfile like ``` FROM python:latest ADD . RUN pip install foo ``` If I run this today, and I run this a year from now, I'm going to different versions of `python` and `foo` and there is no way (with just the Dockerfile) to know which version of `foo` and `python` were intended. Nix on the other hand, forces me to use a git sha[^0] of my dependency; there is no concept of a mutable input. So to your point it's hard to 'upgrade' from version a -> b in a controlled fashion if you don't know what `a` even was. [0]: or the sha256 of the depedency which yes, I understand that's not easy for humans to use.
      - ofrzeta 2y ago
        Well, what about "FROM python:3.18" and using requirements.txt or something like that? I mean, running an arbitrary Python version will get you in trouble anyway.
        2y ago
- agumonkey 2y ago
  eelco thesis: 2003 lxc: 2008 docker: ~2012
- mazambazz 2y ago
  Nix and containerization aren't drop-in replacements for each other. You can use Nix to build containers. Containers on their own don't guarantee reproducibility, especially if the build process isn't static and pure ( how many times do we `sudo apt update` inside a Dockerfile )? And not everything is going to be containerizable. That only works for most applications. What if we're trying to manage our cloud servers? That's where Nix really shines. Do you really think that Nix developers don't know how to containerize applications? You think people are using Nix because they refuse to learn how to containerize, and therefore opt to learn a _much more_ difficult and arcane build process? The logic doesn't track there.
- Cyph0n 2y ago
  Nix handles containerization better than Docker does. Here is a flake that builds a Go app and a Docker image for it (based on headless Chrome): https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0407f7f595ca205a4f6/flake.nix#L69 https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0... And here is how the image is built in CI: https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0407f7f595ca205a4f6/.github/workflows/package.yml#L36 https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...
  - lolinder 2y ago
    You're going to need to do more than just link to the flake if you want to show why that's better than the Dockerfile equivalent, because the code itself isn't selling it.
    - Cyph0n 2y ago
      1. Unbelievable layer reuse out of the box. Each Nix build output is placed in its own layer, including your binary (up to a max of 120 or so layers). Rebuilding the image will only result in the final layer changing, which minimizes work on image push. 2. Everything is pinned to nixpkgs, including dependencies. Anyone who builds this image will get the exact same versions (vs. apt-get update in a Dockerfile pulling a more recent version). It’s just sqlite in this case, but you can imagine how it would work with more dependencies. 3. It is trivial to build a “FROM scratch” image - in fact, that’s the default behavior in Nix, because Nix implicitly includes all runtime dependencies alongside your binary. This is less of a challenge with Go, but YMMV with other languages. 4. You can define your entrypoint script - or any other one-off script - in-line. Not a huge advantage, but still quite useful. There is even an alternative pattern that allows you to reap these same benefits directly in your Dockerfile: https://mitchellh.com/writing/nix-with-dockerfiles https://mitchellh.com/writing/nix-with-dockerfiles Hope that helps.
  - knoopx 2y ago
    here is a derivation that fetches https://www.usememos.com/ https://www.usememos.com/ from source, changes the color palette, builds a docker image out of it and spins up a container that traefik exposes automatically: https://gist.github.com/knoopx/afde5e01389e3b8446f469c056e59953 https://gist.github.com/knoopx/afde5e01389e3b8446f469c056e59...
- azeirah 2y ago
  Huh? I use Nix to create containers. Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools. The entire reason why I use Nix in the first place is because it allows me to containerize with _better_ reproducibility than docker itself. I do get where you're coming from though. It's not immediately clear that Nix can do all this stuff. Nix is a lot more than just "glorified weird package manager". At its core, Nix is a way to specify dependencies in a mathematically sound manner. Once you have that pure dependency graph managed with Nix, you can start doing the _real_ fun stuff. Like, you can containerize it. Or you can create a VM from it, or an ISO, or a NixOS distribution with _only_ that package installed. Nix actually makes containerization _easier_, not harder. But yes, I empathize. Nix is a mess and it is difficult to understand, it will take a few more years before it is fully settled. In the meantime? I'm going all-in on Nix (the philosophy, not necessarily any particular variant) because I really strongly believe this is the way forward.
  - ofrzeta 2y ago
    > Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools You have identified part of the problem.
    - azeirah 2y ago
      I agree. This _is_ a huge problem.
- turboponyy 2y ago
  Containerizing an application is far easier than packaging an application for Nix - I think most avid Nix users would agree with that. The reason why Nix users "refuse" to containerize is that Nix packages and their associated ecosystem come with a host of benefits that their containerized counterparts do not.
  - deleted 2y ago
    [deleted]
- rcxdude 2y ago
  containers with build scripts are a bandaid over broken systems, it's better practice then having zero executable documentation on how to stand up a system, but it's also far from the best that could exist.
- exe34 2y ago
  no thank you.
vendiddy 2y ago
This is how I feel about Nix. I've given it a try and it's quite incredible how easy certain things are. The problem is the Nix language and the developer experience are really rough. There's a chance that Nix could figure this out or a competitor with Nix-like ideas could become mainstream. That's my hope anyway. It would be a shame if the ideas behind Nix got dismissed because of the current issues with Nix.

rob_c 2y ago

It's basically, I refuse to learn how to containerize. Just learn, use, promote best practices and stop forking the ecosystem _even_ further... There, I got that off my chest.

jvandreae 2y ago
The problem with docker is less the containerization and more the half-baked build system.
jjmarr 2y ago
Well, yeah. Nix is attempting to be better than containerization. Saying "improvements aren't necessary because we already have 'good-enough' technology" is a meaningful argument when the improvements aren't significant. In my view, they are significant because Nix can be used to create a fully featured OS instead of just a VM.
- pzmarzly 2y ago
  > they are significant because Nix can be used to create a fully featured OS instead of just a VM Look up Bootable Containers project by RedHat [0]. Fully featured OS built from a Containerfile, bootable on bare metal. I agree that Nix design is much better than Docker, and has a bunch of features that OCI ecosystem doesn't (e.g. remote builds[1], partial downloading of the build tree, non-linear build process[2], nix store import/export, overlays, I/O isolation, much better composability), but "creating OS instead of VM" [did you mean container?] is not one of them. [0] https://github.com/containers/bootc https://github.com/containers/bootc [1] You can use DOCKER_HOST, and I'm happy that this option is there, but Nix does it better. [2] Perhaps with BuildKit it's no longer true, I haven't checked what happens if you have multi-staged build with one stage depending on multiple previous ones (which are otherwise unconnected). I think Earthly can parallelize this scenario https://earthly.dev/ https://earthly.dev/
  - cpuguy83 2y ago
    Yes buildkit can do this. You can also use buildkit to create a bootable VM, just that nobody is doing it. You can use estargz to fetch just the pieces you need from a dependency rather than the entire depdency as well. Really all of the things you mentioned should be possible with buildkit, just that the focus of most things is Dockerfile which has much more limited functionality (though some of the things mentioned above still apply to Dockerfile).
edude03 2y ago
As a heavy container user myself - I've been using containers since I needed to build my own 3.x kernel to test them - docker doesn't solve the reproducibility problem nix solves - IE, I can make a Dockerfile that does `RUN curl foo.com/install.sh` and who knows if that'll work ever again. Nix on the other hand doesn't allow you to do IO during builds[^0] only describe the effect of doing the IO. [0]: Though apparently darwin (mac) doesn't support sandboxing by default, so you can bypass that but anyway
- XorNot 2y ago
  You can just store the actual container though. Which will reproduce the environment exactly, it's just not a guidebook on how it was built. The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact reproduction: what we want is the ability to record what was important and effect upgrades.
  - edude03 2y ago
    I'm not talking about a bit perfect reproduction though, just being able to understand dependencies. Take for example a simple Dockerfile like ``` FROM python:latest ADD . RUN pip install foo ``` If I run this today, and I run this a year from now, I'm going to different versions of `python` and `foo` and there is no way (with just the Dockerfile) to know which version of `foo` and `python` were intended. Nix on the other hand, forces me to use a git sha[^0] of my dependency; there is no concept of a mutable input. So to your point it's hard to 'upgrade' from version a -> b in a controlled fashion if you don't know what `a` even was. [0]: or the sha256 of the depedency which yes, I understand that's not easy for humans to use.
    - ofrzeta 2y ago
      Well, what about "FROM python:3.18" and using requirements.txt or something like that? I mean, running an arbitrary Python version will get you in trouble anyway.
      - 2y ago
agumonkey 2y ago
eelco thesis: 2003 lxc: 2008 docker: ~2012
mazambazz 2y ago
Nix and containerization aren't drop-in replacements for each other. You can use Nix to build containers. Containers on their own don't guarantee reproducibility, especially if the build process isn't static and pure ( how many times do we `sudo apt update` inside a Dockerfile )? And not everything is going to be containerizable. That only works for most applications. What if we're trying to manage our cloud servers? That's where Nix really shines. Do you really think that Nix developers don't know how to containerize applications? You think people are using Nix because they refuse to learn how to containerize, and therefore opt to learn a _much more_ difficult and arcane build process? The logic doesn't track there.
Cyph0n 2y ago
Nix handles containerization better than Docker does. Here is a flake that builds a Go app and a Docker image for it (based on headless Chrome): https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0407f7f595ca205a4f6/flake.nix#L69 https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0... And here is how the image is built in CI: https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0407f7f595ca205a4f6/.github/workflows/package.yml#L36 https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...
- lolinder 2y ago
  You're going to need to do more than just link to the flake if you want to show why that's better than the Dockerfile equivalent, because the code itself isn't selling it.
  - Cyph0n 2y ago
    1. Unbelievable layer reuse out of the box. Each Nix build output is placed in its own layer, including your binary (up to a max of 120 or so layers). Rebuilding the image will only result in the final layer changing, which minimizes work on image push. 2. Everything is pinned to nixpkgs, including dependencies. Anyone who builds this image will get the exact same versions (vs. apt-get update in a Dockerfile pulling a more recent version). It’s just sqlite in this case, but you can imagine how it would work with more dependencies. 3. It is trivial to build a “FROM scratch” image - in fact, that’s the default behavior in Nix, because Nix implicitly includes all runtime dependencies alongside your binary. This is less of a challenge with Go, but YMMV with other languages. 4. You can define your entrypoint script - or any other one-off script - in-line. Not a huge advantage, but still quite useful. There is even an alternative pattern that allows you to reap these same benefits directly in your Dockerfile: https://mitchellh.com/writing/nix-with-dockerfiles https://mitchellh.com/writing/nix-with-dockerfiles Hope that helps.
- knoopx 2y ago
  here is a derivation that fetches https://www.usememos.com/ https://www.usememos.com/ from source, changes the color palette, builds a docker image out of it and spins up a container that traefik exposes automatically: https://gist.github.com/knoopx/afde5e01389e3b8446f469c056e59953 https://gist.github.com/knoopx/afde5e01389e3b8446f469c056e59...
azeirah 2y ago
Huh? I use Nix to create containers. Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools. The entire reason why I use Nix in the first place is because it allows me to containerize with _better_ reproducibility than docker itself. I do get where you're coming from though. It's not immediately clear that Nix can do all this stuff. Nix is a lot more than just "glorified weird package manager". At its core, Nix is a way to specify dependencies in a mathematically sound manner. Once you have that pure dependency graph managed with Nix, you can start doing the _real_ fun stuff. Like, you can containerize it. Or you can create a VM from it, or an ISO, or a NixOS distribution with _only_ that package installed. Nix actually makes containerization _easier_, not harder. But yes, I empathize. Nix is a mess and it is difficult to understand, it will take a few more years before it is fully settled. In the meantime? I'm going all-in on Nix (the philosophy, not necessarily any particular variant) because I really strongly believe this is the way forward.
- ofrzeta 2y ago
  > Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools You have identified part of the problem.
  - azeirah 2y ago
    I agree. This _is_ a huge problem.
turboponyy 2y ago
Containerizing an application is far easier than packaging an application for Nix - I think most avid Nix users would agree with that. The reason why Nix users "refuse" to containerize is that Nix packages and their associated ecosystem come with a host of benefits that their containerized counterparts do not.
- deleted 2y ago
  [deleted]
rcxdude 2y ago
containers with build scripts are a bandaid over broken systems, it's better practice then having zero executable documentation on how to stand up a system, but it's also far from the best that could exist.
exe34 2y ago
no thank you.

vendiddy 2y ago

This is how I feel about Nix. I've given it a try and it's quite incredible how easy certain things are. The problem is the Nix language and the developer experience are really rough. There's a chance that Nix could figure this out or a competitor with Nix-like ideas could become mainstream. That's my hope anyway. It would be a shame if the ideas behind Nix got dismissed because of the current issues with Nix.