Guix for Development
dthompson.us56 points by clircle 6 days ago
56 points by clircle 6 days ago
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)
[0]: https://sprites.dev
[1]: https://exe.dev
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.
This is where I'm at after using Nix for a few years for different use cases. I never want to write it again, and would welcome a Scheme over Nix.
You can run Nix packages on Guix if there isn't a "native" package for it. Look at nix-service.
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...
Im with you. As an emacsen, i feel it’s natural for me to use Guix, but nix is so so much more popular… :/
Guix being a GNU project the purism also doesn't help. Just look at this: https://github.com/nonguix/nonguix
I don't even disagree that nonfree software is bad, but blaming the users who often have no choice in the matter (e.g. drivers) is the wrong way to go.
It's a little inconvenient but for example my Framework laptop Intel WiFi chip requires a binary blob and I want aware of this. Now that I am, I can make better hardware purchasing decisions. There are plenty of alternatives that don't require that blob and it's the only thing I need from the no free channel.
I really don't think you can gain much realistic freedom going without the blob. The powers that be will never let you have a freely modifiable radio transceiver.
The blob is better viewed as a part of the hardware in this case. What's most likely to happen to get rid of the blob is to just put it on the non-modifiable parts of the device. Viewed in this way, the blob is at least something you can practically inspect, unlike the firmware on the chip itself.
See also the discussion on CPU microcode:
https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002...
Are there really a lot of alternative Wifi chips that don't require closed blobs? Do you have a list?
Are they found in any laptop that is reasonably available on the market?
I don't think that Guix is punishing users by not supporting non-libre hardware. They are making a choice in what they develop and anybody of similar mind can join their effort.
The nonguix folks are practical. It just stinks that nothing ships with a Wifi chip that doesn't require nonguix pragmatism.
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!
> 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?
While not directly mentioned in this article, guix pack[1] allows you to distribute your software in multiple formats, including Docker images.
The general philosophy of Guix is to have a single definition for how to build your software and use it for the entire dev to production pipeline.
[1]: https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix...
In Nix (and, I’d assume, for Guix) you can go the other way around: https://mitchellh.com/writing/nix-with-dockerfiles.
As a side benefit, the generated docker image can be very tiny.
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.
both guix and nix are 1000% better for setting up and managing per-project deps deterministically
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.
I think they're two different tools. Containers are great for production environments. Beside reproducibility, they also give control over resources and manage virtual devices. Things that are rather not needed during development.