[HN Gopher] Trying Guix: A Nixer's impressions
       ___________________________________________________________________
        
       Trying Guix: A Nixer's impressions
        
       Author : todsacerdoti
       Score  : 127 points
       Date   : 2025-07-15 08:11 UTC (3 days ago)
        
 (HTM) web link (tazj.in)
 (TXT) w3m dump (tazj.in)
        
       | idlip wrote:
       | 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.
        
         | kwk1 wrote:
         | Guix recently moved from Savannah to Codeberg, which hopefully
         | will help move the needle on infrastructure and volunteer
         | quantity concerns.
        
         | tempfile wrote:
         | 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.
        
           | kyoji wrote:
           | 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.
        
             | tadfisher wrote:
             | 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.
        
               | opan wrote:
               | >(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.
        
           | kwk1 wrote:
           | 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.
        
           | nbf_1995 wrote:
           | 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.
        
           | positron26 wrote:
           | 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.
        
             | kwk1 wrote:
             | Agreed on the assessment, but for me, part of the appeal of
             | Guix is a way to turn that ship around.
        
             | pmarreck wrote:
             | isn't there nonguix? you know, the Ashley Madison of guix?
        
             | bheadmaster wrote:
             | > what has had FSF backing and been successful?
             | 
             | GCC is still indispensable. I doubt it will be rewritten in
             | Rust any time soon.
        
               | positron26 wrote:
               | 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.
        
               | pxc wrote:
               | 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.
        
             | davexunit wrote:
             | 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.
        
             | sshine wrote:
             | > _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/
        
             | johnisgood wrote:
             | > Outside of coreutils that are about to be fully subsumed
             | by rewrite-it-in-Rust
             | 
             | Highly doubtful to happen anytime soon.
        
           | davexunit wrote:
           | Regular updates do not take anywhere near a half hour.
        
         | msgilligan wrote:
         | > 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.
        
         | exe34 wrote:
         | 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.
        
       | CBLT wrote:
       | 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).
        
       | pkulak wrote:
       | > 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.
        
         | realo wrote:
         | I like flakes... I use flakes.
         | 
         | You love flakes... keep using them!
         | 
         | The rest is politics.
        
           | pkulak wrote:
           | For sure. But I find other people's opinions interesting.
        
         | hamandcheese wrote:
         | - 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.
        
         | dawnofdusk wrote:
         | I mean they get evaluated in a weird way: for example you
         | cannot use the `rec` keyword when declaring inputs.
        
       | peterldowns wrote:
       | 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.
        
         | otabdeveloper4 wrote:
         | > 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.
        
           | grep_name wrote:
           | > 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
        
         | positron26 wrote:
         | > 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.
        
           | jdudjxxjz wrote:
           | Cgmm
           | 
           | Comando gomsss456 scqd game
        
         | xrd wrote:
         | 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.
        
       | hamandcheese wrote:
       | The main thing holding me back from trying guix is that, as far
       | as I know, there is no support for macOS.
        
         | umanwizard wrote:
         | Correct, Guix is Linux and Hurd only.
        
       ___________________________________________________________________
       (page generated 2025-07-18 23:00 UTC)