> I've never had such high introspection ability as with Guix.
I actually feel the opposite, the fact that guile does not have edebug-style step debugging support or better tooling in general in Emacs, when both are GNU projects, is nutty to me.
Makes more sense to stick to Nix IMHO because of the better package ecosystem, bigger community, and general pragmatism.
I hope to find a more consistent use for guix, is just that I mostly forget about it. My default package manager (xbps) has pretty much everything I need and the rest are either so obscure that I need to patch and compile by hand or are proprietary stuff that I just run an AppImage and are done.
I had a use for it sometime ago that I needed to compile Tcl, and it was a breeze to do! But outside of such niche things I haven’t found a use for guix
Coming from Nix (guix's more popular, but less freedom-focused cousin).. I think part of what makes Nix "next generation" is that its functionality allows for more powerful use than "install/upgrade/uninstall package".
It's neat to be able to use some program without having to install/uninstall it.
I find it useful to be able to programmatically declare a set of packages (& lock their versions) that I want available when working on a project.
guix allows the user to do those things as well. Ephemeral shells with packages made available and specific environment declarations as a file are both documented and mature.
They seem to have been pointing at Nix since they're more familiar, but acknowledging that Guix is similar in most regards. ("guix's more popular, but less freedom-focused cousin")
Guix is very focused on "free" software and as such is very limiting. IE, if you want to use Discord, Slack, or Steam on guix you're going to have to figure that out yourself.
Nix makes this much easier and you're much more likely to find ready made packages for even esoteric software. Nix has over 3 times as much software as Guix.
Nix also goes for a lot more composability than guix with nix flakes. It makes it nearly trivial to package any software you want.
You may want to give Nix a try if you had trouble with Guix.
The way to use discord/slack/steam/teams/[proprietary nonfree app that you can’t build yoirself] on Guix is to install Flatpak and run it in a sandbox.
I don't use Guix, but I do use Nix, and packaging is by far the easiest thing to write in it (perhaps but surprisingly). OS modules, environments, and dev-shells are all where I would like some help...
There is nix-gui, but development appears to be dead. It seems like most of the community is focused on flakes, with things like the recent announcement of flake hub allowing them to be shared more easily. So we'll have packages of packages, hopefully without all the duplicate dependencies that currently exist.
- on the one hand you have the general warm fuzzy feelings associated with a considerately-designed graphical tool to lower a barrier to entry
- and the fact that this tool was as trivial to implement as a cursory glance at the repo suggests vindicates the whole guix/nix declarative packaging idea. the ease with which ten lines in a text editor turned a new piece of software into a first-class citizen on my system was the thing that hooked me on nix forever
but that's just it: is this really lowering the barrier to entry all that much? the audience guixsd/nixos is courting is someone sick and tired of managing config files strewn across the filesystem. by definition that is someone who knows how to operate a text editor, at which point "look at how few keystrokes/memorised file paths you need on our system vs debian/arch/whatever to gain the same thing" feels like enough of a sales pitch
in terms of attention economy, this is like going "what costs you a dollar on debian costs you a dime here... hey check this out now it's 9 cents if you want. neat, huh?"
I can see myself using this even though I know how to do most of this stuff. I don't have the exact syntax of a package memorised and I think this is probably the easiest way to write one. It doesn't have to be revolutionary, just convenient.
Slight OT, but while we are on the monthly guix topic here, let me shamelessly plug https://the-dam.org/, a public-access server running GNU Guix. It will let you try it out, and chat with other individuals who are also curious about guix.
An update is coming "soon" where you'll be able to mount 9P2000.L servers from guix containers, something that is currently impossible due to Linux mount namespaces not allowing anything but basically fuse.
You'll be able to try all the new packages you'll create with the GUI tool from TFA.
> An update is coming "soon" where you'll be able to mount 9P2000.L servers from guix containers, something that is currently impossible due to Linux mount namespaces not allowing anything but basically fuse.
Guix has a more palatable language than nix to me. However I have pretty much no interest in interacting with gnu projects. I don't share the ideology strong enough to put up with it. So it stays in the "cool tech, won't use" category for me.
I had the same hangups, with Guix being way easier to grok than Nix.
The non-guix repository and their substitute has you covered in the non-gnu side of things. You can use a regular kernel (read:not linix-libre) and it downloads all the required microcode and drivers.
My experience with other GNU projects is that the community will give you a cold shoulder if you ask about a problem involving non-free software;[1] I have been told that this is not as much the case with Guix, so I may try it out.
1: And this is perfectly fine; communities can and should have such standards, but it will be off-putting to those who do not share the same values.
From what I've seen, they will point you in the direction of where you can get further info about non GNU resources, but they wont provide the extra effort of debugging your code. They're otherwise pretty kind/willing.
> nix is off - I can't work out what parameters are needed for any one function call they all appear to be in a global namespace.
If you are talking about something you saw in the nixpkgs repo, then that is probably the callPackage design pattern [0], which is basically a form of automatic dependency injection.
It definitely made it hard for me to grok how nixpkgs package definitions worked at first - there was so much stuff getting injected dynamically, without any trace of where those dependencies lived.
The callPackage pattern is an important piece that allows you to override a dependency with a different version, though, which is essential when customizing existing packages for your own needs.
I'd say Nix-the-language isn't that hard or weird. Nixpkgs-the-standard-library is much, much harder, and basically undocumented. Nixpkgs-the-repository is nice and search.nixos.org works well.
It's the opposite to me. Guile is an exercise in pain and suffering to read. While nix is definitely not perfect it's essentially json with some cherries on top.
There's definitely a huge gap in the perception and the actual learning cost of the language part of Nix. There's few things to know about the language: JSON data types, functions, conditionals, and a small number of operators (arithmetic, concatenation, etc.). But there's so many people drawing comparisons with Haskell for, uh, apparently no reason other than to make it seem harder than it actually is.
Hrm, I disagree. I think a functional language is a difficult transition, but the transition is worth it. If you want to be able to do things idiomatically in Nix and understand what you’re doing, there is a learning curve. It’s not a higher learning curve than a computer science bachelor will allow you to push past, but many people don’t have that background either. Quality training materials bridge that gap. If Rust and Haskell can do it, Nix can too.
One day I hope to return to Guix, I've never had such high introspection ability as with Guix.