There's a few points to make here, actually, based on discussion of the article in the weeks before it hit HN:

Two major and immediate reasons why the pulling is slow are clear and fixable:

1. Guix will try to substitute from unreachable caches for a LONG time before giving up, and Guix infrastructure is less developed than Nix. When I kept experimenting after this post I set up https://mirror.yandex.ru/mirrors/guix/ eventually which fixes the substitute problems for me (Guix mirror on bigcorp infra).

2. Guix by default pulls its channel from GNU Savannah which, for some reason, is incredibly slow in serving git. The project moved over to Codeberg, and setting the URL to there significantly speeds up pulling.

In NixOS, channels (esp. the unstable ones) advance when CI finishes building a certain subset of packages successfully (this is what https://status.nixos.org/ shows). CI populates the binary cache, so this means that a channel HEAD always has a large number of packages available in the cache. Guix has no such guarantees, so updating to any latest commit might even yield one where you end up rebuilding all of its Scheme from scratch or whatever. Picking a commit that's a few days old helps with this.

I eventually switched to a laptop with a "normal" Intel CPU, and pulling did not magically turn fast. In fact, some of the slowest stages (there's one where it says "Computing Guix derivation") don't seem to exercise the CPU much at all. I haven't spent time looking at why (yet).

Guix System does a lot more per-user stuff than NixOS by default, which means that you'll likely end up pulling multiple times.

Pulling remains a much slower operation than Nix evaluation in any case.

There's a few ways to make this all more palatable (e.g. the `guix time-machine -C $channels` setup), but those might be for a follow-up post in the future.

I think that also one needs to be familiar with modifying the guix daemon service to allow substitutes be downloaded so that you don't have to build derivations [0], [1].

Once you modify the guix daemon service and approve the substitute server keys with `guix archive`, your experience should be much faster.

[0]: https://guix.gnu.org/manual/en/html_node/Substitute-Server-A...

[1]: https://guix.gnu.org/manual/en/html_node/Getting-Substitutes...

It doesn't usually take that long, but the first `guix pull` is quite slow, and what should be a no-op of running it a second time immediately afterwards also takes too long.

Edit: Just to provide a measurement, on my Framework 13 with AMD Ryzen 5 7640U, a `guix pull` which pulled in 1 nonguix commit and 64 guix commits took 2m10s, and a subsequent no-op `guix pull` took 1m18s.

From the article:

> My goal was to take my Unchartevice laptop with its strange Zhaoxin x86_64-compatible CPU...

> Sure, this is a laptop with a CPU broadly equivalent to old Intel Atom CPUs...

Yes, guix pull is slow, but the author is using some old/exotic hardware. The last time I tried guix on a 5th gen dual core i5, the initial pull was not that slow. And as other commenters have pointed out. The first pull is the slowest by far.

I play around with a Guix install in a VM, and with less than half of my system resources, a `guix pull` with a `guix system reconfigure ...` takes about 10 minutes. That said, if a pull happens to include a kernel update it can take much longer. I think pinning large packages (like the kernel) that may not need incidental updating is key to keeping pull times lower.

Important question is if its fixable.

Nix is pathologically recursive, lazy, and uses fixed points, things that are very apt to changing something that cascades through a bunch of dependents. Nix's runtime is not magic. Guile should be able to expose a language and evaluate it in a similar way.

For my part, I've not opted into Guix because it's a GNU project, and I've decided to avoid anything in the FSF sphere of influence. Their orthodoxy turns off contributors and they have a history of taking insular hard-liner approaches that are utopian. Outside of coreutils that are about to be fully subsumed by rewrite-it-in-Rust (which has a community that is not a fan of the GPL), what has had FSF backing and been successful? Linus starts two of the most influential pieces of software in human civilization and RMS wants to name the awards. The pragmatic culture that shifted away from the FSF has I think largely adopted Nix, and it shows. Nix is open for business, available on lots of platforms, has commercial entities built around its success.

Regular updates do not take anywhere near a half hour.