Why did you choose the nix you nix?

Determinate Nix is the "corporate" version. It's run by big names in the Nix ecosystem but there's perennial concerns about them not upstreaming improvements, trying to shove features in, whatever. I don't know if it has any compelling benefits over cppnix.

Lix I like because it feels like they're trying to fix a lot of the papercuts that are involved in the ecosystem, untangle the gnarly codebase, and so on. AFAIK there are no incompatibilities between it and cppnix unless you do weird stuff.

Guix has the advantage of using a proper language and first class home-manager(-equivalent) support. The biggest downside is that it's a gnu project so nonfree software support will always be secondary, and IIRC there were still enough sharp edges when I tried it that I went back to Lix. But I wish them well and hope they succeed!

So I'd say either Lix (if you want to be able to interop with the broader Nix ecosystem) or Guix (if you like Scheme, copyleft, or a more cohesive system).

AFAIK none of snix/tvix/etc are usable as a replacement for the cppnix binary in the way Lix/Detsys Nix are.

Lix because I trust the dev team more than any other Nix-like, with Guix as a close second in that regard. Not Guix because I don't like lisp and I do like the convenience of the world's largest package repository.

I just use regular Nix.

I chose Lix because I like the idea of Nix with community-first principles that takes Rust seriously, and really I only chose it over Guix because Nix is more popular and will have more industry usage as time goes on. Guix is probably cooler but being Lisp it'll never be popular enough that a guy like me could get employed to work with it.

if you aren't sure, just use the primary implementation (nix / cppnix). it's the most well-supported, with the largest community around it, and the most nix developers and nix / nixos contributors working on it. the vast majority of people working on nixos use nix.

detnix is for detsys to move faster and do things specific to their clients' needs without being impeded by the development cadence of upstream nix, and to do things that upstream nix wouldn't accept for various reasons. there is effectively no reason to use this unless you're a client of detsys because the benefits don't really manifest without a support contract. they have a few cool things that won't be upstreamed, but you aren't going to find help in the main nix/nixos support channels using them, and they are arguably less battle-tested by nature of simply having fewer users that only do things on the happy path.

lix has a bunch of objectives, but at the present moment it's effectively upstream nix with some decent dreams (e.g., "demoting" flakes from core into a form of plugin system, and levelling the playing field for alternative implementations of similar ideas) and, in various areas, cleaned-up code. largely they haven't deviated far enough from upstream nix yet for it to matter from an end-user perspective, but right now there's no point locking in to using it if you're in a position where you're asking this question. the improvements between (cpp)nix and lix are cyclical, with a lot of them in one ending up in the other, because there is significant development overlap. it's also a bit more "community-focused", but said community is very small.

guix the implementation is an entirely different story. it's for guix the operating system, and has a bunch of different expectations entirely. the only similarity is that it uses some components of the nix store. a sibling comment mentions that it uses a "proper language" which is an implication i'd suggest isn't quite correct—nix is indeed a "proper language". "it uses a general-purpose language" would be more apt: nix the language is focused exclusively on package management, whereas guix uses a full scheme (guile, specifically). if you're interested in nix/nixos, guix is not the thing for this. if you're interested in the guix ecosystem, guix is the only thing for this, but that comes with significant tradeoffs in general usability and mainstream-ness (e.g., the init system, the package ecosystem, the attitudes towards "non-free" things).

snix (superseding tvix) and co. are reimplementations from scratch that aren't "there" enough to be used day-to-day yet. they are working hard on closing this gap but it's a massive job.

i just use (cpp)nix, but i keep a close eye on lix and snix. once lix figure out the flakes thing and a decent alternative crops up i'll probably migrate to that, because flakes do have material deficiencies that can't really be fixed without a massive amount of work due to how tightly they are wound into the the nix implementation. snix interests me "because rust" and also because a greenfield implementation has the opportunity to fix many things that would require large refactors otherwise, but it has a long way to go from at this moment.

Guix for the community, documentation, and it turned out that I found the embedded domain specific language in scheme to be more ergonomic for my tastes. I used Nix for a year prior to my switch in 2015.

I run Guix on my machines and servers.

I like the community and its ethos. The contributors are absolutely brilliant.

I was fascinated with Scheme, wanted to try one, and found that Guix is a brilliant way to use a Scheme practically.

Since the community is small, one has a lot of space to shine. Not that I have grabbed this opportunity yet, thanks to my infant.

I love their experiments:

• Guix built its own init system Shepherd, and keeps it working against non-trivial shifts like Gnome's increasing dependency on systemd.

• Love guix deploy. I used it to deploy a guix system on Hetzner VPS. I had to use a patched version though, the stock hetzner script was buggy then.