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.

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! :)

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.

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

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

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

ecosystem size and less friction for non-free software.