4 ms·

Many design decisions are different. Nix and Guix are each other's Bizarro. It's a common misconception that Guix is just "Nix with Scheme" or "Nix without syst

Many design decisions are different. Nix and Guix are each other's Bizarro. It's a common misconception that Guix is just "Nix with Scheme" or "Nix without systemd" but those are frankly the least interesting differences. An example is that the package definitions sit in the same repo as the package manager, freeing the definition language to evolve without regard for compatibility (because they will always be read by the correct version of Guix) whereas Nix has to freeze the definition language and always test that old definitions work. Obviously there are pros and cons to each approach. https://guix.gnu.org/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ https://guix.gnu.org/blog/2018/multi-dimensional-transaction...

the_duke 5y ago
Can you elaborate on those differences? The concepts seemed pretty similar to me.
- medstrom 5y ago
  Added an example. Also the dev communities care about slightly different things. They match my tastes, we find the same kinds of things cool, so I've found nothing but joy in Guix. One matter of practical impact is how they prioritize blurring the line between user and contributor -- "uplifting" users into contributors as much as possible. I saw that as the biggest flaw of Gentoo, it was very hard to even know how to start contributing.
  - Blikkentrekker 5y ago
    Perhaps you should try Exherbo then. They take the opposite approach and insist that all users be contributors and are often unwilling to provide support to users that aren't at least somewhat contributing back. Their dream is a system where all users are contributors.
    - medstrom 5y ago
      https://www.exherbo.org/ https://www.exherbo.org/ That does sound nice. I'd like to know how it differs from Guix.
      - Blikkentrekker 5y ago
        It's package manager is more so similar to Portage; and it can in fact be used on Gentoo as an alternative thereto.
  - geeksix 5y ago
    > they prioritize blurring the line between user and contributor -- "uplifting" users into contributors as much as possible Can you explain more about this? How do they uplift?
- civodul 5y ago
  For a detailed "Guix vs. Nix" comparison, see: https://news.ycombinator.com/item?id=16490027 https://news.ycombinator.com/item?id=16490027 and https://news.ycombinator.com/item?id=23529932 https://news.ycombinator.com/item?id=23529932. In a nutshell, these are two different projects, with common foundations, but also different technology and different focuses--just like Julia and Clang are different, even though they both use LLVM. The project blogs and documentation should already give a feel of how those differences play in practice!
  - the_duke 5y ago
    I had read both of those before. The first one primarily just says "we use Scheme instead of Nix lang". There are some differences that emerge from that, but most of what is described is also common or possible with Nix. The analogy of clang vs Julia does not fit for me. Nothing I've seen has yet described any significant difference, but rather affirmed that both are very similar in most regards.
    - medstrom 5y ago
      It's not just Nix lang it replaces, we use Scheme in place of a hodgepodge of languages (shell script, Nix, C and others). Almost all equivalents to C-hardcoded parts of Nix is inspectable and modifiable in Guix. There's code reuse across the stack. Even the systemd substitute is opened up for inspection and modification. Nix glues a lot of black boxes; Guix is a single white box. Both approaches are practical for different reasons.
mwill 5y ago
As someone who lives in nixos about 90% of the time, I really do just want Nix but LISP, and if thats what Guix was I would have switched a long time ago
georgyo 5y ago
The embedded package repository is actually a major con IMHO. Making backwards incompatible changes is easy inside your monorepo, but if you a user building software it means that your code now depends on specific guix reversions as well as a specific commit. In nix land, the more stable API means we are moving further into composible modules. Meaning you can now very easily have all your companies code in different (or one big) repositories that can reference each other easily. However having used both guix and nix for several years now, I am firmly in camp they are the same. The porcelain of guix is much nicer, but each can do everything the other does. To me guix and nix are similar to a comparison of fedora and ubuntu. Both fedora and ubuntu are fairly different, but there is there is a 1:1 method to do everything in one in the other. Having only used fedora, you could easily figure out ubuntu. Everything is essentially done the exact same way, but different tools. The same is true with guix and nix.
- medstrom 5y ago
  The Guix way moves more contribution upstream (it's very easy to get your PR accepted) and less people having their own untested "PPAs" everywhere. People have this image that having a private channel is simpler/faster somehow as it skips hoops but in Guix it's just not true (what hoops?). You can submit PR after PR after PR for something only you would ever care about. The main reason not to is when you want to keep your codebase secret, right? Composible modules are certainly another solution. I don't know what's ultimately best but I think we could perhaps make it easier to pin a specific Guix revision. Perhaps require it. It already runs different versions of itself so often, it's part of the way it should work.
  - mrslave 5y ago
    > less people having their own untested "PPAs" everywhere This is not my experience with Nix. 1. My system configuration pulls in a couple of programs in from unstable for my convenience and it was incredibly easy. 2. I don't do any serious 3rd-party packages or package configuration at the system level. Instead, any package configuration (e.g. overrides, Docker images) and 3rd-party packages absent from Nixpkgs - usually pretty easy to write, if not trivial - are defined in the repository where they are required. They are used - and tested - and reproducable to the pinned Nixpkgs in that repository. It has been incredibly easier than PPAs and Gentoo overlays. Presumably safer too (though this is an incomplete thought). To be fair the learning curve was medium, and I didn't invest any serious effort. Instead I made progress until frustrated and asked colleagues to help a few times until I grokked it. From the perspective of a simple user, the single system configuration file is a killer feature even if you don't venture any further.

the_duke 5y ago

Can you elaborate on those differences? The concepts seemed pretty similar to me.

medstrom 5y ago
Added an example. Also the dev communities care about slightly different things. They match my tastes, we find the same kinds of things cool, so I've found nothing but joy in Guix. One matter of practical impact is how they prioritize blurring the line between user and contributor -- "uplifting" users into contributors as much as possible. I saw that as the biggest flaw of Gentoo, it was very hard to even know how to start contributing.
- Blikkentrekker 5y ago
  Perhaps you should try Exherbo then. They take the opposite approach and insist that all users be contributors and are often unwilling to provide support to users that aren't at least somewhat contributing back. Their dream is a system where all users are contributors.
  - medstrom 5y ago
    https://www.exherbo.org/ https://www.exherbo.org/ That does sound nice. I'd like to know how it differs from Guix.
    - Blikkentrekker 5y ago
      It's package manager is more so similar to Portage; and it can in fact be used on Gentoo as an alternative thereto.
- geeksix 5y ago
  > they prioritize blurring the line between user and contributor -- "uplifting" users into contributors as much as possible Can you explain more about this? How do they uplift?
civodul 5y ago
For a detailed "Guix vs. Nix" comparison, see: https://news.ycombinator.com/item?id=16490027 https://news.ycombinator.com/item?id=16490027 and https://news.ycombinator.com/item?id=23529932 https://news.ycombinator.com/item?id=23529932. In a nutshell, these are two different projects, with common foundations, but also different technology and different focuses--just like Julia and Clang are different, even though they both use LLVM. The project blogs and documentation should already give a feel of how those differences play in practice!
- the_duke 5y ago
  I had read both of those before. The first one primarily just says "we use Scheme instead of Nix lang". There are some differences that emerge from that, but most of what is described is also common or possible with Nix. The analogy of clang vs Julia does not fit for me. Nothing I've seen has yet described any significant difference, but rather affirmed that both are very similar in most regards.
  - medstrom 5y ago
    It's not just Nix lang it replaces, we use Scheme in place of a hodgepodge of languages (shell script, Nix, C and others). Almost all equivalents to C-hardcoded parts of Nix is inspectable and modifiable in Guix. There's code reuse across the stack. Even the systemd substitute is opened up for inspection and modification. Nix glues a lot of black boxes; Guix is a single white box. Both approaches are practical for different reasons.

mwill 5y ago

As someone who lives in nixos about 90% of the time, I really do just want Nix but LISP, and if thats what Guix was I would have switched a long time ago

georgyo 5y ago

The embedded package repository is actually a major con IMHO. Making backwards incompatible changes is easy inside your monorepo, but if you a user building software it means that your code now depends on specific guix reversions as well as a specific commit. In nix land, the more stable API means we are moving further into composible modules. Meaning you can now very easily have all your companies code in different (or one big) repositories that can reference each other easily. However having used both guix and nix for several years now, I am firmly in camp they are the same. The porcelain of guix is much nicer, but each can do everything the other does. To me guix and nix are similar to a comparison of fedora and ubuntu. Both fedora and ubuntu are fairly different, but there is there is a 1:1 method to do everything in one in the other. Having only used fedora, you could easily figure out ubuntu. Everything is essentially done the exact same way, but different tools. The same is true with guix and nix.

medstrom 5y ago
The Guix way moves more contribution upstream (it's very easy to get your PR accepted) and less people having their own untested "PPAs" everywhere. People have this image that having a private channel is simpler/faster somehow as it skips hoops but in Guix it's just not true (what hoops?). You can submit PR after PR after PR for something only you would ever care about. The main reason not to is when you want to keep your codebase secret, right? Composible modules are certainly another solution. I don't know what's ultimately best but I think we could perhaps make it easier to pin a specific Guix revision. Perhaps require it. It already runs different versions of itself so often, it's part of the way it should work.
- mrslave 5y ago
  > less people having their own untested "PPAs" everywhere This is not my experience with Nix. 1. My system configuration pulls in a couple of programs in from unstable for my convenience and it was incredibly easy. 2. I don't do any serious 3rd-party packages or package configuration at the system level. Instead, any package configuration (e.g. overrides, Docker images) and 3rd-party packages absent from Nixpkgs - usually pretty easy to write, if not trivial - are defined in the repository where they are required. They are used - and tested - and reproducable to the pinned Nixpkgs in that repository. It has been incredibly easier than PPAs and Gentoo overlays. Presumably safer too (though this is an incomplete thought). To be fair the learning curve was medium, and I didn't invest any serious effort. Instead I made progress until frustrated and asked colleagues to help a few times until I grokked it. From the perspective of a simple user, the single system configuration file is a killer feature even if you don't venture any further.