Basing their killer app, the package manager, on a weird Haskell-like semi-functional undocumented language was a major faux pas of the project in my opinion. Guix is certainly easier to understand and hack, but sadly too "GNU" (i.e. orthodox) to be as useful in the real world as NixOS.
Adopting NixOS means learning how everything fits together as well as learning the quirks of a not very intuitive language. Way too make adoption even harder for everyone on the fence.
I agree with you that the Nix language is a problem, and most likely a mistake in hindsight. Even for someone with lots of functional programming experience it's ugly with bad usability. I'm not familiar with Guix, but I am with Nix and
> Guix is an advanced distribution of the GNU operating system
This sounds like it competes (?) with NixOS, but not with Nix. A reason for the popularity of Nix is that it's not only an operating system. Most Nix users probably haven't touched NixOS, but they use Nix as a package manager, build system, development environment, etc on their local machine. That target audience is a lot larger than those who want to adopt a whole new operating system.
This adoption of Nix outside of the operating system context naturally leads to more adoption of NixOS. If you already work with Nix anyway, it's not that huge of a jump towards adopting NixOS.
Initially, I really wanted to use Guix over Nix, but Nix is more mature with more packages, maintainers, and features.
Last I checked, for example, there was no equivalent of a channel or overlay in Guix. Their npm importer was also not released, whereas Nix has a very usable node2nix.
Having done virtually no functional programming, learning Guile Scheme was also a barrier to me, but the Nix expression language felt a lot more natural for whatever reason.
It's unfortunate - I'm very interested in the work in reproducible builds and substitutions Guix has done, maybe it'll take off at some point or those features will be integrated into NixOS.
Guix is definitely a cleaner implementation (coherent cli tooling, way better manual, not a custom, oddball language, ...).
But:
* if Nix is already very niche, Guix is the niche of a niche. The ecosystem is tiny in comparison.
* The Nix interpreter isn't exactly fast, but Guix (with it's scheme) was significantly worse for me, even in relatively small tests
* The hard stance on open source requirements is understandable, given the projects origin, but it will severely hinder adoption. No, I don't want to package every commercial app I need myself. nixpkgs has almost everything.
The documentation and the nix language are the worst things about the project IMO. I really hope Guix succeeds because Scheme is, in my opinion, a better DSL and language than this weird, not very well documented, Haskell-like derivative.
Unless you've drank the kool-aid, you have to learn a completely new operating system and way of doing things, a weird language that's lacking on documentation, and a ton of system or package-specific options that are even less documented, and requires you to spend too much time reading the source to understand what's going on and how to achieve something a little off the beaten path.
Feels a bit cultish IMO, and that only the illuminated ones are able to grok it. That it's my fault I'm not prepared to do the work and see for myself why NixOS is better than any other distro.
I like the idea of NixOS, and I've played with it, but what put me off is the Nix expression language, which was just incomprehensible to me. Guix's language is a bit nicer (since it's just Scheme), and I'm hoping to play more with it when I find the time.
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.
Well this is enough to put anyone off Nix. Such a shame because the abstract idea is obviously a good one. But every time Nix/NixOS comes up the story is the same.
Guix seems interesting but I almost stopped reading when I read "Nix". For all the benefits the Nix ecosystem provides, they haven't crossed the usability gap for me. First was naming their packages so confusingly, Nix the language vs NixOS vs Nix the package manager. Then there's the whole promise of it being usable from multiple platforms ("you don't even have to use NixOS, just use the package manager for awesome builds") -- It was supposedly amazing for building some software packages, but the reality was always so sticky and never quite panned out.
To be fair I have seen/heard lots praise it a lot for delivering stability to the servers they manage, but in this day and age, I'm not sure it's even worth trying to learn something to manage servers when the cattle approach is so much better (just shoot it). Even when stateful applications get involved, distributed storage is springing up to make it easier than ever to take down a server but have the data it had still be accessible, granted it was replicated, and sync if/when the machine ever comes back up. If the world evolves in that direction, it seems like people will only care about packages at VM/container/whatever base layer build time.
Don't want to be the downer here but I don't think it's likely that Guix is going to cross the usability chasm. I've invested a lot of time/interest/effort in projects that were better, but never crossed the usability/mindshare chasm and while I hope I'm wrong, this feels like some of the other ones.
Completely unrelated to that though, this quote rang true to me:
> Guix is a fork of Nix and addresses the main issue that Nix didn’t get right: instead of comming up with a homebrewed domain-specific language (DSL) with its own set of limitations and idiosyncrasies, Guix uses a full-fledged programming language. (And a good one at that, since it’s Guile Scheme, a Lisp-based language.)
I think Hashicorp has this problem with HCL (see the recent updates[0] announced at the last HashiConf, the `for` keyword is now in HCL) -- though I'm not recommending they fix the problem with lisp, people need to stop making DSLs then bridging the gap between their DSL and a full programming language. I much prefer the Pulumi[1]'s approach -- though it leaves devs lots of rope to hang themselves with ("recursive infrastructure building functions...why not?").
Well, Guix started as Nix with established language, and that didn't really made it better.
The Nix language is functional and lazily evaluated, it closely matches how Nix works builds packages, which basically makes it less verbose.
Even if they used python (or python like language like starlark), and then proceed to build an abstractions on top of it, barely documenting the function. Leaving old ones with the new ones, you would still be confused and frustrated needing to look at the source code.
I don't get how people find nix useful. Setting up a python environment, for example, is a total nightmare. Nix lang itself seems completely unnecessary. Guix is using scheme, which I assume people would be more incentivized to learn just because it's a general programming language. So why is nix winning?
I’m all in on Nix (the package manager) today and use it across multiple Linux and Mac machines to handle my configs and most of my app installs.
That said, I still find nix difficult to understand and learn, and when I get stuck on something it seems extremely frustrating to unstick myself.
I would love to try Guix, mostly because I think building on an existing language would have solved many of my issues with nix, but the whole point for me is that I want a stable config across all of my platforms; the “non free” restrictions guix poses has gated me from it.
The thing is, they are competing for package maintainers and users. A Nix package can't be natively used by Guix, and vice-versa, so a package have to be written for both.
I don't know that much about Guix, other than "super-free Nix with scheme" (and the article wasn't particularly illuminating other than boiling down to "Guix isn't really ready for most users right now"), but it's neat that there's momentum in the declarative OS-space. I hope that both Guix and NixOS keep growing and that more people start switching.
After switching to NixOS, I'd find it very frustrating to go back to an OS with imperative-style package/service management. It's clearly the better way.
A frustrating thing about NixOS--coming from Arch Linux and being used to the AUR--is that adding packages/updating packages can be a bit slow due to the sheer volume of PRs/Issues on the nixpkgs repo. There's always the NUR[1] but it hasn't picked up that much momentum yet (probably because it's kind of hard to search the darn thing). Eitherway, the packages are just Nix expressions and repos are just collections of these expressions, so nothing's preventing a real AUR alternative other than momentum.
It's interesting that Guix uses scheme instead of a home-baked configuration language like NixOS. While I don't find Nix particularly offensive, I don't find it particularly great either. And maybe this is naivity/Nix-inexperience on my part speaking, but I really wish that Nix had a proper type system and was strictly typed.
I guess my pipe dream is "HaskellOS" that's basically NixOS configured with Haskell (just think of xmonad-style configuration for your whole OS). That'd be really nice. And my secondary-pipe dream is a baked in, extremely-comprehensive home-manager[2] so we can bid dotfiles goodbye once and for all and have your entire system-state defined in a single file.
I’m probably biased in that I primarily use Emacs and like lisps. So I find guix more approachable right out the box. Learning a new language just to use an OS is quite a big ask and part of the learning hurdle of Nix.
It’s too bad that guix uses old style mailing lists for development though. I just can’t be bothered setting up myself for that mode of contribution, so I’ll continue to use NixOS for the indefinite future.
When I got into Nix and Guix I tried both and I leaned towards Guix because "it's scheme" but ended up sticking to Nix because of maturity, Darwing support and it being way more performant.
In the end I realized that I actually prefer Nix as a language. I like that it's a very simple and limited language, with, for example, no way of performing side-effects. It is tailored towards it's purpose and, while not perfect, it does the job well.
As other point out, Nixpkgs and the Nix toolchain in general just uses very weird names for everything, plus the docs. That's the difficult bit. It's slightly improving over time.
Adopting NixOS means learning how everything fits together as well as learning the quirks of a not very intuitive language. Way too make adoption even harder for everyone on the fence.
reply