Hacker News Reader

Comment by eointierney | Hacker News Reader

I oscillate back and forth between guix and nix. They both do the same thing really well. Nix is more mature, has some amazing capabilities, and is kinda annoying in spots such as documentation. I end up browsing users' repos for both.

Guix is more elegant in ways such as guile versus nix the dsl, although the haskell underpinning of nix is very useful.

If you're a linux user willing to put in the time and play around then both are perfectly usable as daily drivers but they're both learning experiences as well.

Hard to say which will win out, probably both, with excellent interoperability.

They really are the future of os managment, they simplify abstractions of state and naming

View on HN

What kind of interoperability should I expect between Guix and Nix going forward? As I understand, Nix is pretty heavily reliant on systemd for running services while Guix has its own pid1. Last I read Guix was also replacing the daemon with one written in scheme. I think Guix used Nix package format (nar) at one point but not sure if that holds anymore either.

The idea of two functional, declarative package/system managers being interoperable is very exciting for me, if it meant I can use full breadth of Nixpkgs with system config declared in Guile. But is that something I can look forward to or is it too much?

Nix exists as a service for guix. All my system declarations include the nix service. But as far as interop goes I’m not really sure of the value. I think it just sounds neat but hasn’t really been thought through in terms of exactly what that would look like.

> although the haskell underpinning of nix is very useful.

I thought Nix was written in C++?

Nix itself is written in C++, but Nix the language borrows multiple characteristics from Haskell. Nix community and Haskell community are also very comfortable and comingled with each other and Nix is one of the recommended ways to manage Haskell project dependencies.

Haskell and the Nix language are both pure and lazy extensions of lambda calculus, but that's an enormous language space, and Nix's lack of static types makes them pretty distant.

For many Haskellers, I believe the interest stems from how Haskell's "cabal-install" (its closest equivalent to pip, cargo etc) used to be pretty broken. There wasn't universal interest in fixing this, with some insisting that installing dependencies is the job of your distro's package manager, not your language's ecosystem.

Gentoo did an okay job at having coverage of Haskell dependencies, but Nix was the clear leader ever since they could auto-import the hackage database. It's for this sole reason that I moved from Gentoo to Nix.

This pipeline I came through doesn't really exist now, because the Haskell community has endorsed Stackage, and cabal has fixed its core problems by copying the nix solution.

Reply on news.ycombinator.com