Hacker News Reader

Comment by return_to_monke | Hacker News Reader

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

View on HN

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.

Why would you recommend nix/flakes over Docker?

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.

> 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?

Reply on news.ycombinator.com