Guix uses Nix under the hood (learned this when trying to compile it). Perhaps learning Nix first will let the grandparent be more effective in Guix later.

Guix forked and modified only the Nix build daemon which isn't user visible. Learning the Nix tools and language will not teach you very much about how to use Guix.

Guix includes a copy of the nix-daemon. It's a relatively small C++ program that manages the store. We reuse it because there was no point in writing a replacement for something as low-level as the daemon. Guix compiles its package definitions down to the same kind of file format that the old Nix daemon understands.

(It's a bit funny to me that GNU has a reputation for NIH-ing projects, but when a GNU project doesn't reinvent the spokes on a wheel it also attracts various forms of criticism.)

It can get even funnier when Chris Baines replaces the Nix daemon with a new implementation in Guile. Then, the NIH argument can be reused instead.

Any news on that front?

> The daemon also is a key part of the history of Guix. The Guix project started mixing Guile with ideas from the Nix project, and the guix-daemon is a fork of the nix-daemon with some tweaks made over the years. Rather than being implemented in Guile though, the daemon is implemented in C++ with some helpers written in Guile.[1]

[1] https://guix.gnu.org/en/blog/2023/a-build-daemon-in-guile/

---

Found https://github.com/alezost/guile-daemon (https://packages.guix.gnu.org/packages/guile-daemon/), too, which is just as old. Is it "finished"?

I suppose nothing has happened out of https://summerofcode.withgoogle.com/archive/2017/projects/59...?

Is https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/... even relevant today?

The Summer of Code project was unsuccessful for personal reasons. The project was also never even close to high priority, because the daemon just isn't all that interesting beyond performing its one job of implementing the functional package management paradigm. That is to say, for a long time there was very little to be gained from a rewrite.

The most recent project has only just started and is spearheaded by Chris Baines, who has extensive experience with the build side due to his work on a (Guile-based) build coordinator used by one of the two major independent build farms.

I don't think the older branches contain much that needs to be ported; most of the work from past projects has in fact made it into Guix already and is used for other features --- just not in the daemon. If the Guile daemon project is successful, the daemon will incorporate many of these existing features for build isolation and coordination.

What criticism are you referencing? FWIW I'm a moderately pro-NIH person.