4 ms·

Why would you recommend using this over for example GitHub Actions (also free) with a workflow that installs nix and then builds the flake?

jkarni 4y ago
You need to get caching right if the builds aren't going to take forever, which is a bit of work, especially since smart GC is hard, and it can be slow (the nix store gets big very quickly!). Then you also would ideally provide that cache (as a nix store cache) for yourself and others, so you don't have to rebuild it. But GH Actions doesn't do that, so you need to find a way on your own, or pay for a service like Cachix. Pushing the nix cache can be quite slow. Then the logs are formatted in a very nix-unaware way, which makes it hard to find what you want. And Github doesn't yet even have M1 Mac VMs, so you would get to test/cache that. (I think it's also not possible to do other architectures, like aarch64.) Also, for whatever reason (in addition to the specific ones above), GitHub action runners are just slow... In short: garnix is faster, has more features, and is easier to set up.
MuffinFlavored 4y ago
Why would you recommend nix/flakes over Docker?
- jkarni 4y ago
  There are lots of advantages and disadvantages to both, and use cases where one or the other shines. A proper response would probably be a blog post in length, but in brief, I find that Nix really makes everything explicit. You can see the source code and it reflects everything that went into a build; you can also control every bit of it. It is, however, consequently generally more verbose, and also requires a bit more learning. Nix also tends to compose much more cleanly than docker. Maybe an analogy: nix is a package-lock.json. Docker is a package.json (with no version bounds) and a node_modules directory. You can just copy that node_modules directory around so everyone has the same setup, but it's much harder to introspect than a lock file, and the way you go about updating it is deleting the folder and rebuilding everything - no fine-grained control over one specific dependency.
  - MuffinFlavored 4y ago
    > You can see the source code and it reflects everything that went into a build There's no "FROM ...." for Nix like there is for a Dockerfile?

jkarni 4y ago

You need to get caching right if the builds aren't going to take forever, which is a bit of work, especially since smart GC is hard, and it can be slow (the nix store gets big very quickly!). Then you also would ideally provide that cache (as a nix store cache) for yourself and others, so you don't have to rebuild it. But GH Actions doesn't do that, so you need to find a way on your own, or pay for a service like Cachix. Pushing the nix cache can be quite slow. Then the logs are formatted in a very nix-unaware way, which makes it hard to find what you want. And Github doesn't yet even have M1 Mac VMs, so you would get to test/cache that. (I think it's also not possible to do other architectures, like aarch64.) Also, for whatever reason (in addition to the specific ones above), GitHub action runners are just slow... In short: garnix is faster, has more features, and is easier to set up.

MuffinFlavored 4y ago

Why would you recommend nix/flakes over Docker?

jkarni 4y ago
There are lots of advantages and disadvantages to both, and use cases where one or the other shines. A proper response would probably be a blog post in length, but in brief, I find that Nix really makes everything explicit. You can see the source code and it reflects everything that went into a build; you can also control every bit of it. It is, however, consequently generally more verbose, and also requires a bit more learning. Nix also tends to compose much more cleanly than docker. Maybe an analogy: nix is a package-lock.json. Docker is a package.json (with no version bounds) and a node_modules directory. You can just copy that node_modules directory around so everyone has the same setup, but it's much harder to introspect than a lock file, and the way you go about updating it is deleting the folder and rebuilding everything - no fine-grained control over one specific dependency.
- MuffinFlavored 4y ago
  > You can see the source code and it reflects everything that went into a build There's no "FROM ...." for Nix like there is for a Dockerfile?