Its nice read. We need more of comparative posts by user familiar with both nix and guix.
We see bias with most discussions.
Only cons with Guix I see is, lack of infrastructure and less volunteers to work on guix eco-system.
If its solved, I can imagine guix can improve exponentially.
The article focuses on a comparison between GUIX _system_ and NixOS. It would be interesting to see an equally thoughtful comparison that just focuses on GUIX vs. NIX as package managers used on another Linux distribution (e.g. Debian.)
In this case, GUIX might fare better as you won't have to worry about the complexities introduced by binary blobs needed for boot, etc.
Personally, I’d really like a crossplatform declarative package manager in a mainstream or mainstream-style language, where the nixpkgs equivalent can be JITed or AOTed including the shell scripts, so it isn’t painful to work with and can switch into an environment almost instantly.
Though nix the language syntactically isn’t that complex, it’s really the way that nixpkgs and things like overrides are implemented, the lack of a standard interface between environments and Darwin and NixOS, needing overlays with multiple levels of depth, etc that makes things complex.
The infuriating thing about nix is that it’s functionally capable of doing what I want, but it’s patently obvious that the people at the wheel are not particularly inclined to design things for a casual user who cannot keep a hundred idiosyncrasies in their head memorized just to work on their build scripts.
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.
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.
> 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.
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.
For what it's worth the association with GNU is basically historical at this point. RMS has never accepted the original vision of the project (to be the official GNU OS) and the project outgrew GNU's dilapidated infrastructure a long time ago, which the project is finally addressing with the migration to Codeberg. The FSF gave the project a place for people to donate specifically to Guix but have never really embraced it, otherwise. That has been superseded by a dedicated European nonprofit for Guix. The most recent Guix Days gathering before FOSDEM featured a lengthy conversation of breaking ties with GNU entirely but no decision has been made on that, yet.
It seems to me like the better strategy would be to "do the right thing" according to the internal values of the project and make GNU be the one who breaks ties, otherwise the opportunity for positively influencing something important is lost. Still a newcomer though, so that's just my 2c. Hope to be there with y'all in Brussels next year! By the time I found out about it, it was apparently already full.
> Nix is pathologically recursive, lazy, and uses fixed points, things that are very apt to changing something that cascades through a bunch of dependents.
While that may be true, it is particularly the case for nixpkgs; i.e., you may imagine a contender to nixpkgs that is less tangled.
I’ve recently enjoyed reading on research into simpler alternatives; GrizzlT’s deep-dive into nixpkgs design patterns, and nrdxp’s atom format:
Off the top of my head: GCC, Emacs, coreutils, sed, grep, find, parallel, Guile, Coreboot, GNOME, GIMP, GnuPG, Bash
In each case, development is the work of the developers, and they themselves deserve most credit. But the FSF and the GNU project have certainly been involved with lots of software that is important, widely used, and works well.
GNU software is still responsible for huge and often critical chunks of the stack in most Linux distros.
GCC was one subject of The Cathedral and the Bazaar. The development process was changed to more closely mimic Linux and the original GCC steering committee was dissolved. Cygnus had a big role in GCC becoming an industry fixture for its hayday. Eventually the lack of big revenue meant that the license became an annoyance that industry could deal with by nurturing Clang and LLVM with acceptable quantities of money. In FSF orthodoxy, they were supposed to lose that fight.
Not necessarily. In (my understanding of) FSF orthodoxy the existence of a viable GPL alternative forces the hand of competitors in certain respects. LLVM could never drift towards a more proprietary model and expect to succeed at it so long as GCC remains viable.
"Best" doesn't matter, you just need a seed crystal that's good enough.
The vulnerability in the thinking is that if GNU can't reliably get crystals started, if the seeds that make it are dependent on some external force like Cygnus or Linux, and dominant GCC can become has-been GCC, maybe we're looking at an afterglow of some luck and experiment that has a very bleak future if left alone.
Maybe people realized the FSF model isn't sustainable, and a model dependent on mass-volunteerism and religious viral spread of cooperative behaviors falls off when the days become months and the months become years. What if the greys are not being replaced by the dabbers. If that's the case, there won't be another bang.
Maybe see what I'm up to with https://prizeforge.com. I'm hoping to get the MVP functioning with semi-decency today. Mac does not agree with the WASM and I have at least one small dirty hack to execute before I can go live.
Already happening my friend. uutils. It is MIT licensed. Funnily, I recall someone had a story at MIT about not liking passwords. I'm sure they were right?
It may be happening in your bubble, yes, but not outside of that. They are not 1:1 replacements at all, with probably logic bugs introduced (see their Issues page) as well (call them regressions). I would not hold my breath if I were you.
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.
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.
10 minutes is still an order of magnitude slower than a nixos-rebuild if you're hitting the cache, and there's no issue with forgetting to rebuild the guix profile. If you include nonguix (as is required for the 99% of users who need nonfree blobs) you get the 30-50 minutes as described in the article. I believe Nix-the-language being lazily evaluated is a big part of this; you can even inadvertently evaluate nixpkgs multiple times and not notice.
>(as is required for the 99% of users who need nonfree blobs)
If you forgo the built-in WiFi, the ThinkPad T440p (Haswell) works fine without any blobs (speaking from experience). I think all newer gens need iGPU blobs, sadly, but I wanted to point out a viable middle ground between modern Nvidia gamerware setups and Librebooted X200s that can barely browse the web.
Would it be possible to automate nix->guix for packages? A lot of nix packages (e.g. python) I think are handled automatically. If guix could build on that huge package repo, it would really help.
I can’t find the quote right now; but it’s along the lines.
LLM’s can help with the first 80% of coding which is introducing bugs, but terrible at the other 80% of the time which is removing said bugs.
Lean and agile theory says that quality is improved and efficiency gained by going upstream and eliminating the things that are producing poor quality in the first place.
Llm code tools may be useful to give syntax tips, but like a thoughtless dev on a team, likely introduce more work than they get done.
The thing about chatgpt/cursor is that they seem very good at fixing things if they have verbose errors - and nix is very verbose about what it hates in your config. I've given errors to chatgpt and it fixed it for me. With cursor, I had something displaying in a really weird way (plotting a map in js), and I gave it a screenshot and it fixed it immediately.
I would never use llm code in prod without understanding it, but for one-off utilities it has been really great so far.
I'm actually more interested in the Niri "A scrollable-tiling Wayland compositor". It never occurred to me that a valid desktop/windowing paradigm would be one with an infinite horizontal strip. Not sure if I want it, but it's pretty unique.
Think of it less as an "infinite strip" (with implications of windows being lost in the mist, far away) and more as "each workspace is laid out in a strip".
Most of my workspaces have 2-5 columns, with 2-3 fitting on an ultrawide monitor at once.[1]
It's more like "what if tiling window manager, but with even less time spent on adjusting window sizes".
[1]: Let's agree not to talk of the insanity that contains my open browser windows. That is as near infinite as 96 GB RAM lets me have..
I like them both, both interesting, quite similar, both with corner cases
Annoyingly both fail at basic stuff like falling back the graphics card, something Debian had solved 10 years ago, no configs needed, no matter Intel/NVIDIA/AMD. Even without the correct driver or firmware falling back to VESA or fbdev should be a given. Never had so many black screens as now. Even Windows has done better job at giving you a basic resolution while you install the drivers
Or maybe it's just the state of the Linux ecosystem, with the introduction of Wayland and NVIDIA open drivers, causing regressions
Also the unintuitive inverse of traditional package management, where if you want to update one package, all the system updates by default
Which increases the amount of bugs, having frequent updates to a stable system
To make it better you can add 2 channels, and call them nixos-stable v24 nixos-latest v25, keeping most of the system one version down increases stability a lot
Of course the incorporated Grub boot build choices is great to revert back to a working system
I really like the the separation Guix makes on having close source being a concern of a separate project
But both of them are equally easy to install open source only or include proprietary
> But both of them are equally easy to install open source only or include proprietary
Unless it really dramatically changed recently, I don't think that's true. Look, here's the official manual page that describes exactly how to enable use of the non-free packages that are right there in the main nixpkgs repo:
And here's the guix equivalent, maintained in a completely separate repo that you're not allowed to talk about, document, or refer to in any official channels: https://gitlab.com/nonguix/nonguix
Of course they are. Copy and paste a text snippet to your configuration, and run the cli to refresh
Being a separate repo is absolutely OK. Just like installing Nixos's own Home-Manager
Or add other people channels, like adding PPA on Ubuntu/debian. Or run flakes...
Nixos is possibly makes it more confusing by having the documentation recommend `nix-channel --add` instead of the declarative approach. Having the standard declarative, and having flakes on top
And you should probably want to create your own channel. On the week I installed Guix immediately created my channel and packaged ZimWiki
> Of course they are. Copy and paste a text snippet to your configuration, and run the cli to refresh
Even in the best case, that requires you to know about it. When you're not allowed to document the option or even mention it in official support channels, that's harder.
> Being a separate repo is absolutely OK. Just like installing Nixos's own Home-Manager
> Or add other people channels, like adding PPA on Ubuntu/debian. Or run flakes...
> And you should probably want to create your own channel. On the week I installed Guix immediately created my channel and packaged ZimWiki
All of these things make it harder to use and less likely to stay supported.
> Nixos is possibly makes it more confusing by having the documentation recommend `nix-channel --add` instead of the declarative approach. Having the standard declarative, and having flakes on top
So... I agree that that's annoying, and I personally would prefer that everyone agree to use flakes, but AFAIK you don't need to do that to enable unfree in nix? Or is this an unrelated argument against nix that's separate from the point about unfree software?
I had a similar experience. After running `guix pull` a couple of times on an ancient laptop I shelved the project until I made a distcc cluster (I never did).
Very interesting writeup, as a long-time Nix user I've always been interested in trying guix but never gotten around to it. Great post overall.
> The thing is, I'm not actually sure if Guix's better documentation helps smooth the onboarding in any way because you have to already know Scheme, which is a more complex language than Nix.
LMAO absolutely not. Nix-the-language is the worst programming language I've ever had the misfortune to interact with. I picked up Scheme in about 1 day during a class in college. It's night-and-day different.
> Nix-the-language is the worst programming language I've ever had the misfortune to interact with.
I feel the same.
The multi-line strings and string interpolation are both really nice. Unfortunately a lot of the text being munged is bash and usually already ugly, so the result is double-ugly.
The functional aspects are okay. However, as an expression language and being primarily used in a declarative way, it is frequent to have almost no idea what's going on in Nix. Reading the code and understanding the evaluation are extremely far apart.
callPackage... It's something I thought would be cool in a language until I actually experienced the depth of disorientation it can cause.
The remaining syntax has a lot of "but why?" where it just seems to do its own thing relative to other languages, which makes it harder to get into a rhythm.
Some of the subject matter is the real culprit. The cross compiling sliding window thing... I've studied it several times. If I had to actually do something with it, straight to the LLM. Compilers have targets.
So I found some LLMs are wonderful at Nix. A few times I just prompted "port this <github link>" and got a pull request with nix package exactly how I would have written it. One time even manager to implement multiple missing dependencies as well.
> The remaining syntax has a lot of "but why?" where it just seems to do its own thing relative to other languages
Like what?
My list of Nix language nits is relatively small, would like to understand.
One thing that seems under-developed is smart merging. There is // at language level, but then if you want datatype-specific merging, you use functions. That itself is just the power of functional programming. But as it is with untyped languages, you end up doing the same thing slightly different in several places, and a fractal of accidental complexity starts to appear.
I've heard people say "JSON with functions", but I think this is much too generous.
- Functions can be called without delimiters
- AttrSets have lots of delimiting, very explicit syntax
- Lists have absolutely no delimiters again
foo 1 2 is a function call, right?
So if I need it in a list, I can just write: [ foo 1 2 ] right?
Note, we pathologically put spaces around lists in Nix because we are subconsciously sure that something is about to bite us.
[ foo 1 2 ] is a list of three elements, not a function call.
I forget which terrible thing I was doing, but I had a variation of this syntax trap in my code after naively moving the expression into a list. The error message was, as usual, from the Turtles in Time dimension.
The mixture of super explicit and implicit delimiting as well as borrowed ideas like \\ and invented ideas like with and import just make Nix feel like it's all over the place, inconsistent, and doing its own thing when we already had a lot of functional languages to work with.
The evaluation model is completely appropriate for the problem yet pretty unique in programming generally. It has a lot of new ideas that throw even seasoned people well off track. Each new idea is not much, but they compound into not having any idea what we're looking at and watching 50k nixpkgs evaluate just fine while not being able to read any of that code at all.
I'd prefer something like Haskell, Lisp, or Clojure, but please just one. Using Scheme in Guile is a great choice. It's so much easier to read. Hopefully the macros can be developed to bring the best of lazy evaluation into Scheme and fix the runtime issues.
Nix function call syntax is completely standard for ML-style functional languages and allows for effortless partial application. The main downside is that error messages can get cryptic, especially so when Nix is untyped.
Whitespace add list delimiter is not very common, but I have to admit I really like it.
I was hoping for some “this doesn’t work” kind of things, not “this doesn’t feel familiar”.
Not sure how Nix doesn’t win the readability contest: literally a config file with function calls, and as little superfluous syntax as possible. I’d say the real criticism is: Nix is hard to write, and nixpkgs idioms (nested, undocumentedabstractions scattered throughout the code) are hard to read.
A system's purpose is what it does. Nix the language is used to generate bash scripts that are then run in a sandbox, and based on what I'm seeing it's not a great fit/architecture.
(Nix is not a general-purpose language. The concept of store paths etc is hardcoded in it.)
I can complain about the horrible, undebuggable, error messages on the slightest typos too, if you want? Nix is way too subtle to "win the readability contest".
> Nix-the-language is the worst programming language I've ever had the misfortune to interact with
Nix-the-language is just a subset of Javascript with built-in laziness and a slightly different syntax.
An absolute bog-standard and mainstream way of thinking about programs in 2025.
That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development.
> That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development
That must be it. The GP's comment really resonated with me, in that learning scheme felt like no task at all whereas I STILL feel uncomfortable with the nix programming language and ecosystem despite using nixOS exclusively on my personal laptop for two years and on my work machine for about half a year now. I've always fumbled over frontend / javascript development though, and avoid it as much as I can at work although I still end up working in it every year or so.
Nix only won out for me because of the mac compatibility, without which I can't really use it at work
I think nix-the-language is pretty simple and easy to learn language. It's visually hard to parse and a lot of syntax decisions make you wonder, but it's not the worst.
The problem is that you're very rarely exposed to it directly. You are always multiple layers of abstractions away from it. Most of these layers are completely undocumented.
Yes, clearly every general-purpose language like Javascript has specialized the string type for the business domain of text-templating for bash scripts.
I mean, that's a distinction without a difference.
I've not written nix, but javascript is a ugly, terrible language. It would make sense that if nix derives from it (whyyyyyy) it would also be terrible.
I disagree with GP, it’s much more like Haskell than JavaScript. Function application is whitespace, functions can only have one argument, everything is an expression, let blocks are the way you define and scope variables. I see very little relation to JavaScript at all, to be honest.
I don't see any sense where syntactic sugar is not part of the language. I don't really care about how it works behind the scenes, the syntax is the part that I touch as a programmer.
Right, this is a limited, "Windows Subsystem for Linux"-inspired approach meant to get people on macOS a foot in the door to using Guix (System.) It is at least possible though to use GUI applications from the Guix System VM via XQuartz.
After getting used to systemd, I decided to put my toes in the water and try guix. From a user's perspective you never really don't have to care much. Even complex services are pretty simple, and it is really not like you are doing anything different.
The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later.
My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.
> The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later.
This is the main problem. Systemd has the most eyes, and the most active development, and I just don't want to spend innovation tokens on that as well.
> My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.
That's a huge issue. Which also reminds me, this kind of requirement is dead in the water for the GPU era, at least until there are sufficiently F/OSS high quality drivers (which may be never).
Maybe the answer here is to just use only guix the package manager
I don't know if importing systemd would make any difference to the system declaration file that you write, where you'd still declare services in the Lispy way. Does it matter if it translates to systemd services under the hood or not?
> Does it matter if it translates to systemd services under the hood or not?
I think so, because that's what most people are familiar with maintaining/configuring. Systemd at this point is quite robust, and it's sprawling ecosystem has a lot of functionality. Perhaps more importantly, this is the stuff you'll find the most support/integrations for.
- flakes perform very poorly in large repos. This might be changing soon with lazy-trees, but I've been waiting for that for 2+ years.
- flake inputs are not fetched lazily.
- flakes are somewhat restrictive in that you can't override an input with an arbitrary value. This matters if you want to pass in, say, a specially configured nixpkgs object. In practice, for non trivial use cases, flakes fail to solve the problem they set out to solve. Most flakes expose lib functions for these advanced use cases but that's pretty much equivalent to what you get with non-flakes.
Flakes are controversial primarily because they create a parallel ecosystem that breaks compatibility with the traditional Nix workflow, introduce additional complexity without solving core reproducibility issues, and were developed with limited community input despite representing a fundamental shift in how Nix works.
Its nice read. We need more of comparative posts by user familiar with both nix and guix.
We see bias with most discussions.
Only cons with Guix I see is, lack of infrastructure and less volunteers to work on guix eco-system. If its solved, I can imagine guix can improve exponentially.
Guix recently moved from Savannah to Codeberg, which hopefully will help move the needle on infrastructure and volunteer quantity concerns.
> We need more of comparative posts
The article focuses on a comparison between GUIX _system_ and NixOS. It would be interesting to see an equally thoughtful comparison that just focuses on GUIX vs. NIX as package managers used on another Linux distribution (e.g. Debian.)
In this case, GUIX might fare better as you won't have to worry about the complexities introduced by binary blobs needed for boot, etc.
Personally, I’d really like a crossplatform declarative package manager in a mainstream or mainstream-style language, where the nixpkgs equivalent can be JITed or AOTed including the shell scripts, so it isn’t painful to work with and can switch into an environment almost instantly.
Though nix the language syntactically isn’t that complex, it’s really the way that nixpkgs and things like overrides are implemented, the lack of a standard interface between environments and Darwin and NixOS, needing overlays with multiple levels of depth, etc that makes things complex.
The infuriating thing about nix is that it’s functionally capable of doing what I want, but it’s patently obvious that the people at the wheel are not particularly inclined to design things for a casual user who cannot keep a hundred idiosyncrasies in their head memorized just to work on their build scripts.
The major con is in the article, it is super slow to update. Half an hour is just crazy, nobody will move to that if they know.
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.
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.
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.
For what it's worth the association with GNU is basically historical at this point. RMS has never accepted the original vision of the project (to be the official GNU OS) and the project outgrew GNU's dilapidated infrastructure a long time ago, which the project is finally addressing with the migration to Codeberg. The FSF gave the project a place for people to donate specifically to Guix but have never really embraced it, otherwise. That has been superseded by a dedicated European nonprofit for Guix. The most recent Guix Days gathering before FOSDEM featured a lengthy conversation of breaking ties with GNU entirely but no decision has been made on that, yet.
It seems to me like the better strategy would be to "do the right thing" according to the internal values of the project and make GNU be the one who breaks ties, otherwise the opportunity for positively influencing something important is lost. Still a newcomer though, so that's just my 2c. Hope to be there with y'all in Brussels next year! By the time I found out about it, it was apparently already full.
> Nix is pathologically recursive, lazy, and uses fixed points, things that are very apt to changing something that cascades through a bunch of dependents.
While that may be true, it is particularly the case for nixpkgs; i.e., you may imagine a contender to nixpkgs that is less tangled.
I’ve recently enjoyed reading on research into simpler alternatives; GrizzlT’s deep-dive into nixpkgs design patterns, and nrdxp’s atom format:
https://grizzlt.prose.sh/corelib-revolutionary-nixpkgs
https://nrd.sh/blog/atom-anatomy/
> what has had FSF backing and been successful?
GCC is still indispensable. I doubt it will be rewritten in Rust any time soon.
Off the top of my head: GCC, Emacs, coreutils, sed, grep, find, parallel, Guile, Coreboot, GNOME, GIMP, GnuPG, Bash
In each case, development is the work of the developers, and they themselves deserve most credit. But the FSF and the GNU project have certainly been involved with lots of software that is important, widely used, and works well.
GNU software is still responsible for huge and often critical chunks of the stack in most Linux distros.
GCC was one subject of The Cathedral and the Bazaar. The development process was changed to more closely mimic Linux and the original GCC steering committee was dissolved. Cygnus had a big role in GCC becoming an industry fixture for its hayday. Eventually the lack of big revenue meant that the license became an annoyance that industry could deal with by nurturing Clang and LLVM with acceptable quantities of money. In FSF orthodoxy, they were supposed to lose that fight.
Not necessarily. In (my understanding of) FSF orthodoxy the existence of a viable GPL alternative forces the hand of competitors in certain respects. LLVM could never drift towards a more proprietary model and expect to succeed at it so long as GCC remains viable.
"Best" doesn't matter, you just need a seed crystal that's good enough.
The vulnerability in the thinking is that if GNU can't reliably get crystals started, if the seeds that make it are dependent on some external force like Cygnus or Linux, and dominant GCC can become has-been GCC, maybe we're looking at an afterglow of some luck and experiment that has a very bleak future if left alone.
Maybe people realized the FSF model isn't sustainable, and a model dependent on mass-volunteerism and religious viral spread of cooperative behaviors falls off when the days become months and the months become years. What if the greys are not being replaced by the dabbers. If that's the case, there won't be another bang.
Maybe see what I'm up to with https://prizeforge.com. I'm hoping to get the MVP functioning with semi-decency today. Mac does not agree with the WASM and I have at least one small dirty hack to execute before I can go live.
Agreed on the assessment, but for me, part of the appeal of Guix is a way to turn that ship around.
> Outside of coreutils that are about to be fully subsumed by rewrite-it-in-Rust
Highly doubtful to happen anytime soon.
Already happening my friend. uutils. It is MIT licensed. Funnily, I recall someone had a story at MIT about not liking passwords. I'm sure they were right?
Check out the spice: https://users.rust-lang.org/t/im-shocked-the-rust-community-...
I tried just a few months ago. Two shell scripts I use failed due to something wonky with sort.
Everything else worked well enough for my use case.
It may be happening in your bubble, yes, but not outside of that. They are not 1:1 replacements at all, with probably logic bugs introduced (see their Issues page) as well (call them regressions). I would not hold my breath if I were you.
isn't there nonguix? you know, the Ashley Madison of guix?
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...
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.
10 minutes is still an order of magnitude slower than a nixos-rebuild if you're hitting the cache, and there's no issue with forgetting to rebuild the guix profile. If you include nonguix (as is required for the 99% of users who need nonfree blobs) you get the 30-50 minutes as described in the article. I believe Nix-the-language being lazily evaluated is a big part of this; you can even inadvertently evaluate nixpkgs multiple times and not notice.
>(as is required for the 99% of users who need nonfree blobs)
If you forgo the built-in WiFi, the ThinkPad T440p (Haswell) works fine without any blobs (speaking from experience). I think all newer gens need iGPU blobs, sadly, but I wanted to point out a viable middle ground between modern Nvidia gamerware setups and Librebooted X200s that can barely browse the web.
Regular updates do not take anywhere near a half hour.
Would it be possible to automate nix->guix for packages? A lot of nix packages (e.g. python) I think are handled automatically. If guix could build on that huge package repo, it would really help.
I suppose an LLM could easily translate the build scripts. It will not be perfect, but probably will save a lot of work.
I can’t find the quote right now; but it’s along the lines. LLM’s can help with the first 80% of coding which is introducing bugs, but terrible at the other 80% of the time which is removing said bugs.
Lean and agile theory says that quality is improved and efficiency gained by going upstream and eliminating the things that are producing poor quality in the first place.
Llm code tools may be useful to give syntax tips, but like a thoughtless dev on a team, likely introduce more work than they get done.
The thing about chatgpt/cursor is that they seem very good at fixing things if they have verbose errors - and nix is very verbose about what it hates in your config. I've given errors to chatgpt and it fixed it for me. With cursor, I had something displaying in a really weird way (plotting a map in js), and I gave it a screenshot and it fixed it immediately.
I would never use llm code in prod without understanding it, but for one-off utilities it has been really great so far.
I'm actually more interested in the Niri "A scrollable-tiling Wayland compositor". It never occurred to me that a valid desktop/windowing paradigm would be one with an infinite horizontal strip. Not sure if I want it, but it's pretty unique.
https://github.com/YaLTeR/niri?tab=readme-ov-file
Think of it less as an "infinite strip" (with implications of windows being lost in the mist, far away) and more as "each workspace is laid out in a strip".
Most of my workspaces have 2-5 columns, with 2-3 fitting on an ultrawide monitor at once.[1]
It's more like "what if tiling window manager, but with even less time spent on adjusting window sizes".
[1]: Let's agree not to talk of the insanity that contains my open browser windows. That is as near infinite as 96 GB RAM lets me have..
I've switched from wmii (old suckless tiling wm) to niri a couple of months ago and I've been happier with it than with sway/i3 -- give it a shot :)
Scrollable-tiling is the best. Especially if you have two wide monitors side by side.
i used to do something like that with i3. binding meta+tab to go to the next workplace and some combos to move the windows with the same base.
then i realized that it is basically just want i did with compiz or kwin and moved back lol
Is it similar to the Gnome plugin PaperWM?
Yes, Niri is inspired by PaperWM afaik.
I like them both, both interesting, quite similar, both with corner cases
Annoyingly both fail at basic stuff like falling back the graphics card, something Debian had solved 10 years ago, no configs needed, no matter Intel/NVIDIA/AMD. Even without the correct driver or firmware falling back to VESA or fbdev should be a given. Never had so many black screens as now. Even Windows has done better job at giving you a basic resolution while you install the drivers
Or maybe it's just the state of the Linux ecosystem, with the introduction of Wayland and NVIDIA open drivers, causing regressions
Also the unintuitive inverse of traditional package management, where if you want to update one package, all the system updates by default
Which increases the amount of bugs, having frequent updates to a stable system
To make it better you can add 2 channels, and call them nixos-stable v24 nixos-latest v25, keeping most of the system one version down increases stability a lot
Of course the incorporated Grub boot build choices is great to revert back to a working system
I really like the the separation Guix makes on having close source being a concern of a separate project
But both of them are equally easy to install open source only or include proprietary
> But both of them are equally easy to install open source only or include proprietary
Unless it really dramatically changed recently, I don't think that's true. Look, here's the official manual page that describes exactly how to enable use of the non-free packages that are right there in the main nixpkgs repo:
https://nixos.org/manual/nixpkgs/stable/#sec-allow-unfree
And here's the guix equivalent, maintained in a completely separate repo that you're not allowed to talk about, document, or refer to in any official channels: https://gitlab.com/nonguix/nonguix
These are not equal.
> These are not equal.
Of course they are. Copy and paste a text snippet to your configuration, and run the cli to refresh
Being a separate repo is absolutely OK. Just like installing Nixos's own Home-Manager
Or add other people channels, like adding PPA on Ubuntu/debian. Or run flakes...
Nixos is possibly makes it more confusing by having the documentation recommend `nix-channel --add` instead of the declarative approach. Having the standard declarative, and having flakes on top
And you should probably want to create your own channel. On the week I installed Guix immediately created my channel and packaged ZimWiki
> Of course they are. Copy and paste a text snippet to your configuration, and run the cli to refresh
Even in the best case, that requires you to know about it. When you're not allowed to document the option or even mention it in official support channels, that's harder.
> Being a separate repo is absolutely OK. Just like installing Nixos's own Home-Manager
> Or add other people channels, like adding PPA on Ubuntu/debian. Or run flakes...
> And you should probably want to create your own channel. On the week I installed Guix immediately created my channel and packaged ZimWiki
All of these things make it harder to use and less likely to stay supported.
> Nixos is possibly makes it more confusing by having the documentation recommend `nix-channel --add` instead of the declarative approach. Having the standard declarative, and having flakes on top
So... I agree that that's annoying, and I personally would prefer that everyone agree to use flakes, but AFAIK you don't need to do that to enable unfree in nix? Or is this an unrelated argument against nix that's separate from the point about unfree software?
> Also the unintuitive inverse of traditional package management, where if you want to update one package, all the system updates by default
What do you mean? ins't that exactly the arch way ? (no partial update supported)
In Arch if I needed something updated today you would have done
> pacman -Sy
> pacman -S package_name
Leavig the rest system unchanged
In Nixos
> nix-channel --update
> Add package to /etc/nixos/configuration.nix
> nixos-rebuild switch
Which would update everything
Maybe we could do
> nix-channel --update
> nix-env -iA packagename
But I am not sure which version would be installed. And it would definitely go against the purpose of using nixos
> nix-shell -p package_name
It is also quite cool for trying packages without installing permanently
I had a similar experience. After running `guix pull` a couple of times on an ancient laptop I shelved the project until I made a distcc cluster (I never did).
Very interesting writeup, as a long-time Nix user I've always been interested in trying guix but never gotten around to it. Great post overall.
> The thing is, I'm not actually sure if Guix's better documentation helps smooth the onboarding in any way because you have to already know Scheme, which is a more complex language than Nix.
LMAO absolutely not. Nix-the-language is the worst programming language I've ever had the misfortune to interact with. I picked up Scheme in about 1 day during a class in college. It's night-and-day different.
> Nix-the-language is the worst programming language I've ever had the misfortune to interact with.
I feel the same.
The multi-line strings and string interpolation are both really nice. Unfortunately a lot of the text being munged is bash and usually already ugly, so the result is double-ugly.
The functional aspects are okay. However, as an expression language and being primarily used in a declarative way, it is frequent to have almost no idea what's going on in Nix. Reading the code and understanding the evaluation are extremely far apart.
callPackage... It's something I thought would be cool in a language until I actually experienced the depth of disorientation it can cause.
The remaining syntax has a lot of "but why?" where it just seems to do its own thing relative to other languages, which makes it harder to get into a rhythm.
Some of the subject matter is the real culprit. The cross compiling sliding window thing... I've studied it several times. If I had to actually do something with it, straight to the LLM. Compilers have targets.
So I found some LLMs are wonderful at Nix. A few times I just prompted "port this <github link>" and got a pull request with nix package exactly how I would have written it. One time even manager to implement multiple missing dependencies as well.
> The remaining syntax has a lot of "but why?" where it just seems to do its own thing relative to other languages
Like what?
My list of Nix language nits is relatively small, would like to understand.
One thing that seems under-developed is smart merging. There is // at language level, but then if you want datatype-specific merging, you use functions. That itself is just the power of functional programming. But as it is with untyped languages, you end up doing the same thing slightly different in several places, and a fractal of accidental complexity starts to appear.
> Like what?
I've heard people say "JSON with functions", but I think this is much too generous.
- Functions can be called without delimiters
- AttrSets have lots of delimiting, very explicit syntax
- Lists have absolutely no delimiters again
foo 1 2 is a function call, right?
So if I need it in a list, I can just write: [ foo 1 2 ] right?
Note, we pathologically put spaces around lists in Nix because we are subconsciously sure that something is about to bite us.
[ foo 1 2 ] is a list of three elements, not a function call.
I forget which terrible thing I was doing, but I had a variation of this syntax trap in my code after naively moving the expression into a list. The error message was, as usual, from the Turtles in Time dimension.
The mixture of super explicit and implicit delimiting as well as borrowed ideas like \\ and invented ideas like with and import just make Nix feel like it's all over the place, inconsistent, and doing its own thing when we already had a lot of functional languages to work with.
The evaluation model is completely appropriate for the problem yet pretty unique in programming generally. It has a lot of new ideas that throw even seasoned people well off track. Each new idea is not much, but they compound into not having any idea what we're looking at and watching 50k nixpkgs evaluate just fine while not being able to read any of that code at all.
I'd prefer something like Haskell, Lisp, or Clojure, but please just one. Using Scheme in Guile is a great choice. It's so much easier to read. Hopefully the macros can be developed to bring the best of lazy evaluation into Scheme and fix the runtime issues.
Lately I've just been wondering if you couldn't have a python runtime for nix evaluations.
Ultimately we're taking inputs, making derivations and calling some nix specific library functions.
It feels like we should be able to do that with a Python library that would have the major advantage of being step debuggable.
Nix function call syntax is completely standard for ML-style functional languages and allows for effortless partial application. The main downside is that error messages can get cryptic, especially so when Nix is untyped.
Whitespace add list delimiter is not very common, but I have to admit I really like it.
I was hoping for some “this doesn’t work” kind of things, not “this doesn’t feel familiar”.
Not sure how Nix doesn’t win the readability contest: literally a config file with function calls, and as little superfluous syntax as possible. I’d say the real criticism is: Nix is hard to write, and nixpkgs idioms (nested, undocumentedabstractions scattered throughout the code) are hard to read.
> Not sure how Nix doesn’t win the readability contest
Not sure how you can be serious.
https://github.com/NixOS/nixpkgs/blob/d600f006643e074c2ef1d7...
(Do note the Nix escaping on top of the shell horrors.)Nix just comes from a culture of utter utter horrible code. It's my daily driver, but I am holding my nose.
https://github.com/NixOS/nix/blob/94ec9e47030c2a7280503d338f...
I think sshine was saying that the nix *language* is readable. Both of your examples are from the implementation, not the language itself.
A system's purpose is what it does. Nix the language is used to generate bash scripts that are then run in a sandbox, and based on what I'm seeing it's not a great fit/architecture.
(Nix is not a general-purpose language. The concept of store paths etc is hardcoded in it.)
I can complain about the horrible, undebuggable, error messages on the slightest typos too, if you want? Nix is way too subtle to "win the readability contest".
> One thing that seems under-developed is smart merging.
Maybe https://codeberg.org/amjoseph/infuse.nix would be useful? (I find it intriguing, but haven't yet faced a use-case that seemed worth learning it)
[flagged]
> Nix-the-language is the worst programming language I've ever had the misfortune to interact with
Nix-the-language is just a subset of Javascript with built-in laziness and a slightly different syntax. An absolute bog-standard and mainstream way of thinking about programs in 2025.
That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development.
> That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development
That must be it. The GP's comment really resonated with me, in that learning scheme felt like no task at all whereas I STILL feel uncomfortable with the nix programming language and ecosystem despite using nixOS exclusively on my personal laptop for two years and on my work machine for about half a year now. I've always fumbled over frontend / javascript development though, and avoid it as much as I can at work although I still end up working in it every year or so.
Nix only won out for me because of the mac compatibility, without which I can't really use it at work
I think nix-the-language is pretty simple and easy to learn language. It's visually hard to parse and a lot of syntax decisions make you wonder, but it's not the worst.
The problem is that you're very rarely exposed to it directly. You are always multiple layers of abstractions away from it. Most of these layers are completely undocumented.
Yes, clearly every general-purpose language like Javascript has specialized the string type for the business domain of text-templating for bash scripts.
For example: https://shealevy.com/blog/2018/08/05/understanding-nixs-stri...
I mean, that's a distinction without a difference.
I've not written nix, but javascript is a ugly, terrible language. It would make sense that if nix derives from it (whyyyyyy) it would also be terrible.
I disagree with GP, it’s much more like Haskell than JavaScript. Function application is whitespace, functions can only have one argument, everything is an expression, let blocks are the way you define and scope variables. I see very little relation to JavaScript at all, to be honest.
You've listed syntactic sugar, not anything about the actual language.
I don't see any sense where syntactic sugar is not part of the language. I don't really care about how it works behind the scenes, the syntax is the part that I touch as a programmer.
I gotta admit, I stopped reading when I saw nix with scheme. If it was scheme plus nix and it was sorted, I might have continued.
The main thing holding me back from trying guix is that, as far as I know, there is no support for macOS.
Correct, Guix is Linux and Hurd only.
Are people using Hurd still ?
Was anyone ever using it? I assume some nonzero number of hobbyists or true believers still are, but AFAIK those are the only ones who ever were.
At one point arch-hurd had some active members using it enough to update packages
It's still pretty early, but there's a "macOS Subsystem for Guix" project:
https://superkamiguru.org/projects/msg.html
If I understand correctly, that seems to virtualize a Linux system to work, which makes it quite different from nix on macOS.
Right, this is a limited, "Windows Subsystem for Linux"-inspired approach meant to get people on macOS a foot in the door to using Guix (System.) It is at least possible though to use GUI applications from the Guix System VM via XQuartz.
Guix SD will never catch on as long as they force non-systemd management. I don’t care to try Shepherd. Systemd is good enough and it has won.
> I had to use nonguix to get internet working on the machine, which had very immediate technical effects that bring me to
Stuff like this will
The main reasons I’m interested in guix:
- it uses a known-good language (lisp)
- IIRC it is more repeatable (the contents used in derivations play into the hash).
- It has a full source bootstrap
Maybe someone with a focus on improving UX needs to build one of these afresh.
After getting used to systemd, I decided to put my toes in the water and try guix. From a user's perspective you never really don't have to care much. Even complex services are pretty simple, and it is really not like you are doing anything different.
The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later.
My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.
> The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later.
This is the main problem. Systemd has the most eyes, and the most active development, and I just don't want to spend innovation tokens on that as well.
> My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.
That's a huge issue. Which also reminds me, this kind of requirement is dead in the water for the GPU era, at least until there are sufficiently F/OSS high quality drivers (which may be never).
Maybe the answer here is to just use only guix the package manager
I also don't care to try Wayland. Xorg has already won
A lot of people would argue avoiding systemd bloat as a plus
The end user interface for shepherd and systemd are very similar. And probably the least of your worries migrating to a declarative distro
Xorg won? I mean, it has a larger install base probably, but it's also been around significantly longer.
I don't know if importing systemd would make any difference to the system declaration file that you write, where you'd still declare services in the Lispy way. Does it matter if it translates to systemd services under the hood or not?
> Does it matter if it translates to systemd services under the hood or not?
I think so, because that's what most people are familiar with maintaining/configuring. Systemd at this point is quite robust, and it's sprawling ecosystem has a lot of functionality. Perhaps more importantly, this is the stuff you'll find the most support/integrations for.
> why flakes are nonsense
Oh wow, I want to hear more about that. I love flakes, but I've known they are controversial, and never really heard why.
- flakes perform very poorly in large repos. This might be changing soon with lazy-trees, but I've been waiting for that for 2+ years.
- flake inputs are not fetched lazily.
- flakes are somewhat restrictive in that you can't override an input with an arbitrary value. This matters if you want to pass in, say, a specially configured nixpkgs object. In practice, for non trivial use cases, flakes fail to solve the problem they set out to solve. Most flakes expose lib functions for these advanced use cases but that's pretty much equivalent to what you get with non-flakes.
Flakes are controversial primarily because they create a parallel ecosystem that breaks compatibility with the traditional Nix workflow, introduce additional complexity without solving core reproducibility issues, and were developed with limited community input despite representing a fundamental shift in how Nix works.
I like flakes... I use flakes.
You love flakes... keep using them!
The rest is politics.
For sure. But I find other people's opinions interesting.
Here's some of my opinions on flakes, FWIW https://lobste.rs/s/6js1hj/flakes_have_failed#c_byu8ds
I mean they get evaluated in a weird way: for example you cannot use the `rec` keyword when declaring inputs.