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?").

[0]: https://www.hashicorp.com/resources/keynote-terraform-free-s...

[1]: https://pulumi.io/reference/how.html

> 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.

The vast majority of Guix users are on other (so-called "foreign") distributions (i.e. not GuixSD) -- I think the opposite is true for Nix/NixOS.

I'm not sure what's "sticky" about it, can you elaborate?

I meant "sticky" in that when I tried to evaluate NixOS vs CoreOS Container Linux + Ignition (this was a while ago), nix was much harder to install and use than suggested. I ended up going with Container Linux for that very reason and didn't look back.

There was also an issue with nix and docker compatibility that I ran into w/ nix-docker[0], but I don't remember what it was.

Here are some videos I found in my history back when I was exploring Nix (watched in end of 2017/early 2018 I believe):

https://www.youtube.com/watch?v=YbUPdv03ciI

https://www.youtube.com/watch?v=mIxtBVKo7JE

It's entirely possible my anecdata is too old to be useful. Maybe nix is much easier to use (and use correctly) these days. One example of where Nix should have been able to pick up mindshare is with the same people who value linuxkit[1]. Maybe this is is another marketing/branding/hype/money disparity thing but `nix-build '' -A vm` looks like exactly what linuxkit is being lauded/promoted for being a good tool for, and it's been around for so much longer.

[0]: https://github.com/zefhemel/nix-docker

[1]: https://github.com/linuxkit/linuxkit