Always interesting to see an older article come back around. I could probably update this a bit for 2026 but my workflow is just about the same now as it was then. Guix is good and just released 1.5.0, check it out.
Guix looks really tempting to me because i find guile scheme so much more pleasant than nix. But i heard there are not that many packages in Guix. I wonder if some sort of transpiler from nix derivations to guix package definitions would be possible.
I've never felt the need myself. If something is missing, I add it and I think that is the real fun in running Guix because creating your own well defined package or service is deeply rewarding.
Anyway, you can find people using it in the wild either by search engine[1] or with Toys[2] which is also handy for finding examples of missing packages too.
Now if we could just get people to combine Guix and other guile scheme packages that are awesome like mcron into their stacks, and then backfeed more fixes into the ecosystem, we have a real chance at helping GNUland!
I compile nix derivations to well-posed effect/coeffect/graded monad algebra so I can do real bill of materials and build on an action cache engine maintained by professionals, but that's mostly for long-tail stuff.
These days with a la carte access to all of the container ecosystem primitives as nice, ergonomic, orthogonal operations I don't really see the value in nixpkgs. Don't really see the value in a container registry either: a correctly attested content addressable store with some DNS abbreviations is 100 lines of code because mostly it's git and an S3 shim.
The category error at the heart of nixpkgs is that the environment in which software is compiled need resemble the environment in which it executes. Silly stuff. So whether you're a patchelf --rpath ... Person or an unshare --bind-mount Enjoyer (isomorphic), just remember, in 2026 the guy with the daemon that runs as root does not want you to have nice things.
The nix language is maximally lazy. It does not evaluate things it does not need to. This is good because you don't want it to burn CPU building things (very expensive expressions!!) that it will ultimately not need for final derivation. I'm wondering if guix scheme is suited well for this task:
(a) evaluation is eager
(b) lots of variable mutation.
But perhaps lazy evaluation and lack of variable mutation in guix scheme is not such a problem after all for a nix _like_ system -- I don't know.
You can just visit https://repology.org/ and see that GNU Guix has the 5th largest repository, ahead of Fedora and Gentoo. This does not include any proprietary packages, which can be added using https://gitlab.com/nonguix/nonguix (though gitlab seems to be dying for me right now?)
I've been running GNU Guix for five years now, after lots of distro hopping, including to and from NixOS. I left Nix because I found the documentation (particularly regarding the language) to be a struggle to work with (though I imagine it's improved since then).
GNU Guix + nonguix + flatpak is perfectly suitable for everyday use.
Honestly I'm just glad that this declarative approach is steadily being realized. It hasn't hit mainstream adoption yet, but it gives me hope that this headline is making the rounds.
Docker is, as the article describes, just a bandaid and the symptom of unthoughful development foundations.
In the long term, Guix may win out. Probably not in my life time though. But it's a win for developers, and nix really isn't so bad with everyone vibecoding away it's complexity anyways.
> Dockerfiles are clunky and the rather extreme level of isolation is usually unnecessary and makes things overly complicated
I agree, for local development docker is often overkill.
However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent.
And at that point, you're maintaining the Dockerfile anyway, so why not use it for local dev as well? That way your dev and production environments can be close to identical.
Guix looks nice - probably nicer than docker for dev work. But is it nice enough to justify maintaining two separate systems and have your dev and production diverge?
Your production deployment might be done with container images, but Dockerfile is not the only way to build them. Guix has builtin support to build container images without Dockerfile.
I feel like declarative container-like dev environments (e.g. nix shell or guix shell, and so on) will become much more popular in the following years with the rise of LLM agentic tools. It seems that the aformentioned tools provide much more value when they can get full access to the dev environment.
Sprites[0], exe.dev[1], and more services seem to be focusing on providing instant VMs for these use cases, but for me it seems like it's a waste for users to have to ssh into a separate cloud server (and feel the latency) just to get a clean dev environment. I feel that a similar tool where you can get a clean slate dev environment from a declarative description locally, without all of the overhead and the weight of Docker or VMs would be very welcomed.
(Note: I am not trying to inject AI-hype on a Guix-related post, I do realize that the audience of LLM tools and Guix would be quite different, this is just an observation)
I wanted to go all-in on Guix but the installation process was made too difficult due to the lack of non-free software available during install time. I wish they would take the Debian approach and leave it up to the user to decide which packages they would like installed on their system or not.
I love Guile over Nix syntax, but the one killer feature Nix has that Guix doesn’t is making a single static binary of common programs and then deploying them elsewhere.
In Nix, this is a single flag. In Guix, you either deploy with all libraries on a custom /guix path, or nothing.
How is the scheme syntax in any way an improvement over JSON? Can't they build the same thing but use JSON - which everyone already uses - instead of pushing a new verbose syntax?
What if a piece of software isn't packaged, like for example the ARM GCC toolchain. In a Dockerfile I just need to curl and unpack it. How do I solve that with guix?
I use nix, but I assume the same goes for guix, you write a package or run it with something that emulates a FHS (like steam-run, don't mind the name) and hope it works.
Writing a package is not as bad as it sounds, nix and guix have very little difference between "package maintainer" and "user" so most users probably can package software. Normally copying something from nixpkgs or similar will get you most the way there.
The idea was to show that there are several "levels" to take advantage of Guix for development, where the `guix.scm` file in David Thompson's blog post is the first level.
27 comments
[ 4.7 ms ] story [ 48.7 ms ] threadhttps://news.ycombinator.com/item?id=46732047
https://guix.gnu.org/manual/1.5.0/en/html_node/Miscellaneous...
I've never felt the need myself. If something is missing, I add it and I think that is the real fun in running Guix because creating your own well defined package or service is deeply rewarding.
Anyway, you can find people using it in the wild either by search engine[1] or with Toys[2] which is also handy for finding examples of missing packages too.
[1]: https://duckduckgo.com/?t=fpas&q=%22config.scm%22+nix-servic...
[2]: https://toys.whereis.social
These days with a la carte access to all of the container ecosystem primitives as nice, ergonomic, orthogonal operations I don't really see the value in nixpkgs. Don't really see the value in a container registry either: a correctly attested content addressable store with some DNS abbreviations is 100 lines of code because mostly it's git and an S3 shim.
The category error at the heart of nixpkgs is that the environment in which software is compiled need resemble the environment in which it executes. Silly stuff. So whether you're a patchelf --rpath ... Person or an unshare --bind-mount Enjoyer (isomorphic), just remember, in 2026 the guy with the daemon that runs as root does not want you to have nice things.
(a) evaluation is eager
(b) lots of variable mutation.
But perhaps lazy evaluation and lack of variable mutation in guix scheme is not such a problem after all for a nix _like_ system -- I don't know.
I've been running GNU Guix for five years now, after lots of distro hopping, including to and from NixOS. I left Nix because I found the documentation (particularly regarding the language) to be a struggle to work with (though I imagine it's improved since then).
GNU Guix + nonguix + flatpak is perfectly suitable for everyday use.
Docker is, as the article describes, just a bandaid and the symptom of unthoughful development foundations.
In the long term, Guix may win out. Probably not in my life time though. But it's a win for developers, and nix really isn't so bad with everyone vibecoding away it's complexity anyways.
I agree, for local development docker is often overkill.
However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent.
And at that point, you're maintaining the Dockerfile anyway, so why not use it for local dev as well? That way your dev and production environments can be close to identical.
Guix looks nice - probably nicer than docker for dev work. But is it nice enough to justify maintaining two separate systems and have your dev and production diverge?
Sprites[0], exe.dev[1], and more services seem to be focusing on providing instant VMs for these use cases, but for me it seems like it's a waste for users to have to ssh into a separate cloud server (and feel the latency) just to get a clean dev environment. I feel that a similar tool where you can get a clean slate dev environment from a declarative description locally, without all of the overhead and the weight of Docker or VMs would be very welcomed.
(Note: I am not trying to inject AI-hype on a Guix-related post, I do realize that the audience of LLM tools and Guix would be quite different, this is just an observation)
[0]: https://sprites.dev
[1]: https://exe.dev
LLMs have also made writing syntacticly correct Nix scripts much easier, so I don't miss Guix's Guile that much.
In Nix, this is a single flag. In Guix, you either deploy with all libraries on a custom /guix path, or nothing.
Writing a package is not as bad as it sounds, nix and guix have very little difference between "package maintainer" and "user" so most users probably can package software. Normally copying something from nixpkgs or similar will get you most the way there.
But i woudn't expect less from some hijackers.
https://guix.gnu.org/donate/
Proof:
https://donate.stripe.com/8x2bJ133ia2H3Zw4j38N201
https://donate.stripe.com/aFaeVd7jy7Uz1Ro02N8N204
https://donate.stripe.com/dRm5kD47m0s79jQ9Dn8N202
https://guix.gnu.org/cookbook/en/html_node/Software-Developm...
The idea was to show that there are several "levels" to take advantage of Guix for development, where the `guix.scm` file in David Thompson's blog post is the first level.