Hacker News Reader

Comment by yewenjie | Hacker News Reader

Guix/GuixSD is great - it has some awesome ideas that still hasn't made it to Nix/NixOS - the only impractical part is number of packages in Guix is really small compared to Nix - and to do anything that is not hardliner FLOSS you have to really grok the entire thing and build everything yourself.

I checked rde almost two years ago - this video was mostly the only documentation back then. IIRC I think now it is even officially part of Guix?

Anyway, I really wish there existed a rewrite of Nix in a saner language, that embraced the new ideas, and still had the pragmatic approach of current nixpkgs.

View on HN

> build everything yourself

That’s not true; Guix allows you to easily fetch pre-built artifacts from “substitution servers”. This becomes even more foolproof now that the packaging system has mapped the whole derivation and the hashes of each component involved.

> to do anything that is not hardliner FLOSS you have to really grok the entire thing and build everything yourself

There’s now a “nonguix” repository/channel for derivations of non-free software (along with its own substitution server for pre-built artifacts).

> the only impractical part is number of packages in Guix is really small compared to Nix

For reference Guix has 21,798 packages while Nix has 80,000+.

I think another issue with Guix is that some packages just seem to go away after a while, and it's a tiny bit inconvenient to get at older versions once they've slipped out:

https://unix.stackexchange.com/questions/698811/in-guix-how-...

That said I'm all for guix over nix (though day to day I use neither) because I think a full programming language is the better tool for this use case (in my mind terraform vs pulumi all over again).

Also there's one more issue which is related to guix's avoidance of binary blobs -- IIRC this means stuff like gfx drivers can be hard to come by/make work and I think this is by design.

Before that just meant that gamers maybe were left out (they weren't really the focus anyway), but now it might leave out a whole bunch of AI enthusiasts as well.

I've given both the package managers a shot with home-manager and Guix home running on Ubunutu. I enjoyed guix a lot, but because it's so focused on building from source installing software took a very long time. Maybe my setup wasn't right, but it would often take several minutes to install a package because it had to compile a bunch of dependencies. I've since moved back to Nix for the day to day, but I may try guix again at some point.

Did you try using “substitution servers”? They supply pre-built artifacts.

Looks like we've found a piece of documentation that needs to be more clearly called out! :)

Guix has more stuff in it now than Nixpkgs did when I started daily driving NixOS. I'd say it's quite usable, especially if you're willing to package whatever extras you need.

Encouragingly, as well, the Guix package collection is growing at an exponential rate (as is Nixpkgs). In a few years there'll be twice as many packages or more, so if you can make it work now, it won't be tough to stick with it.

Nix is a full programming language, just a really idiosyncratic one with syntax only a mother could love.

I've been using lisp for over 20 years now and would much prefer if guile replaced the nix language (or Common Lisp, if I can dream), but I still use NixOS for practical reasons.

I don't mind the nix language, and I far prefer it to lisp.

But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations. It would be able to use stuff from nixpkgs as well, at least partially anyway.

The built derivations are an extremely simple format anything can produce.

If I understand correctly, Guix can do this. Of course the derivation is the final output, so you lose all of the nix modules and nix packages, which kind of defeats the purpose of using NixOS.

I don't think you nessairly need to give up interop. Kinda like his JavaScript can call wasm modules. The compiler would need to know how to use nixpkgs, but the user could write their derivations any way they see fit.

You can depend on other derivations rather easily, but interoperating with functions written in the nix language is more challenging. (And without nix language interop, basically all of NixOS that isn't nixpkgs is useless).

> But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations

This is originally how Guix worked— it generated .drv files in the same format as Nix and then asked a Nix daemon to build them. But both projects consider the derivation format an implementation detail that should be free for them to change according to the needs of the rest of the stack, rather than a stable interface for downstream consumers (be they end users or other software tools).

The above is not just theoretical— as a result, the derivation formats of the two projects have diverged.

(Tbh I agree with their position, though. I don't think the concept of the derivation should really be visible to end users. The way the term is used is extremely overloaded/ambiguous, and so at the end of the day it's jargon that serves more to obscure than to teach.)

what are these practical reasons -- ecosystem size? tooling/documentation?

ecosystem size and less friction for non-free software.

Could you share a bit about what new ideas Guix has?

What do you not like about Nixlang? I think it's quite nice and an especially well-suited DSL for the problems it tries to solve.

>Anyway, I really wish there existed a rewrite of Nix in a saner language, that embraced the new ideas, and still had the pragmatic approach of current nixpkgs.

I'd love something like this but in HCL

As a user of Nix for several years who has only recently taken up HCL: why? They're already very similar languages.

Reply on news.ycombinator.com