8 ms·

Guix interface is a bit more friendly by default, but once you enable the 'nix' command on NixOS, there really isn't much of difference in terms of basic CLI ex

Guix interface is a bit more friendly by default, but once you enable the 'nix' command on NixOS, there really isn't much of difference in terms of basic CLI experience. The big different is the language and I think Nix wins here by a mile. Doing everything with Scheme just leads to layers of macro spaghetti that I really did not enjoy to dig through. Error messages that tell you absolutely nothing about what went wrong were pretty common. Nix has those too, but less frequently. Also with Nix you just use regular shell scripts snippets for the building the packages, Guix wants you to do it all in Scheme. Package selection on NixOS is much bigger. Another big thing, Nix has Flakes, which make it trivially to turn all your Git repositories into Nix packages. Your Git repository becomes essentially a first class citizen in the package manager, making it completely trivial to run different versions of the same software. Guix has none of that, they still treat packages as a separate thing from the software itself and trying to add third party packages involves quite a bit of overhead. Easily up or downgrading individual software isn't possible as far as I can tell, you have have to roll back the complete Guix system to do so. Basically, after switching from Guix to NixOS, I can't say I missed anything. NixOS just felt like a more polished and feature rich version of what Guix was doing, which given that Guix is basically a NIH version of Nix, is understandable.

josteink 4y ago
> Doing everything with Scheme just leads to layers of macro spaghetti that I really did not enjoy to dig through. On the flip side, it’s a real language, well understood, with a real specification, working tooling, and community support outside Guix (or in the case of Nix, outside the package manager). As someone who gave up NixOS exactly because of the incomprehensibleness of the Nix language, I know what I would choose. There’s no doubt at all.
- grumbel 4y ago
  I see nothing especially incomprehensible about Nix, the language itself pretty simple. About the only thing I had a bit of an issue with is that I kept forgetting that functions only take a single argument in Nix. But other than that it is very nice to work with and has all the syntactic sugar you want, string interpolation, sets/map, sane multi-line strings and all that. Syntactic sugar is an area where Scheme has basically nothing to offer, everything needs calls to functions with long names. For most common uses you barely even have to care about the language, as it's just some JSON-like data with shell scripts in between that do the actual work.
  - parminya 4y ago
    The language very much generates complaints because it is gives you no real help understanding what argument should be passed to what function and how to get that argument. Error messages are dreadful because there's often a million functions your object has to go through before it produces an error. Dynamic typing and lazy evaluation don't seem to mix. Some kind of compile-time, presumably gradual, type system would really be an incredible improvement, so that type errors were generally eager.
    - pxc 4y ago
      > Dynamic typing and lazy evaluation don't seem to mix. Incidentally, this is one of the things that some of the people involved with the blog post in the OP have set out to fix. A few years ago, Théophane (author of the blog post) started an experiment to add gradual typing to Nix, which eventually became the start of Nickel: https://github.com/tweag/nickel https://github.com/tweag/nickel Today, Nickel development continues at Tweag, but now they have someone else, Yann Hamdaoui, driving the implementation forward. (I assume because he's a domain expert in programming languages.) Producing helpful error messages is one of the major goals of Nickel, as a potential successor language to Nix. All of the language design decisions are documented as GitHub issues on the repo, so if the technical side of this kind of problem is interesting to you, you may enjoy browsing that. It appears that Nickel is very close to a usable state for early experimentation. You might be interested in cloning the repo and messing around with it!
- baby 4y ago
  Honestly I’ve done enough scheme to understand that I wouldn’t touch anything related with scheme in a million years. People who think otherwise probably don’t understand why people like javascript and python and will never write any product that catches on. The nix language is pretty nice on the other hand. The only thing I’m missing is a language server protocol thing so I can go to definition
  - t0astbread 4y ago
    rnix-lsp is a language server for Nix that provides go to definition. I'm using it with the "Nix IDE" extension in VS Code. It doesn't handle imports though afaict, so it's only useful for local definitions.
  - axlprose 4y ago
    > People who think otherwise probably don’t understand why people like javascript and python and will never write any product that catches on. Ironically, this has been posted on a popular site written in a dialect of scheme: http://arclanguage.org/ http://arclanguage.org/ https://github.com/arclanguage/anarki https://github.com/arclanguage/anarki
    - baby 4y ago
      how is this ironic? HN was written by one person, and nobody needs to care what language they used to make it work.
    - meltedcapacitor 4y ago
      Where is the irony? HN does not expose scheme to the user. Don't think the parent was saying that it's impossible to write a good program in scheme/lisp, more that scheme as user interface for a software system is a hard sell... which seems anecdotally true.
jyrkesh 4y ago
> Another big thing, Nix has Flakes, which make it trivially to turn all your Git repositories into Nix packages. I have no doubt that this is true, but I still feel dumb about it. I run a Plex server (among a few other workloads) on a NixOS box, and just figuring out how to update the Plex binaries off of the official master branch was a multi-hour back-and-forth endeavor between StackOverflow suggestions and compiler errors. I really do love Nix though. And once I got it working I felt a LITTLE bit smarter, AND it's worked flawlessly for months.
- benreesman 4y ago
  I’ve said this elsewhere in the thread and might do so again but it bears repeating: use flakes. At first they seem like this weird semi-supported thing, but eventually you realize that Nix is badly broken without them. Flakes aren’t “experimental”. “Experimental” is what happens to your sanity without them.
  - yjftsjthsd-h 4y ago
    > Flakes aren’t “experimental”. “Experimental” is what happens to your sanity without them. Okay, I like flakes, I use flakes, I enable flakes without much worry. But. They literally are an experimental feature, and they are still enabled by setting "experimental-features = nix-command flakes" in nix's config.
    - benreesman 4y ago
      I think I was maybe too casual with my language. Flakes are clearly marked experimental in the documentation. But they were a no-brainer a year ago, they’re always “a few months” from being official, they map directly onto users’ intuition around lock files, they enable principled composition of shit that doesn’t live in nixpkgs, the list goes on. Outside of some (hypothetical to me) edge cases, not using them is masochism. Flakes have a standard library (“flake-utils”) and and a pimped out version (“flake-utils-plus”). Making it a weird gymnastics trick for a novice user to even access them is the kind of shit GHC devs say, “no, that’s too user-hostile even for us”. Use flakes.
Smaug123 4y ago
It's not quite true that it's trivial to turn a Git repo into a flake, because flakes don't do submodules, and https://github.com/NixOS/nix/pull/5497 https://github.com/NixOS/nix/pull/5497 has languished :(
- grumbel 4y ago
  You can fix that by adding '?submodules=1' to the URL. It does get rather annoying when compiling local code, as that turns a simple 'nix build' into: nix build "git+file://$(pwd)?submodules=1" But it will work with submodules. Another mild annoyance related to this is that Flake inputs can't be expressions, this can make it a rather difficult to fetch dependencies that aren't packaged in a way understood by the existing fetch methods.
  - microtonal 4y ago
    as that turns a simple 'nix build' into Which reveals another annoying thing about using flakes for development. It copies every time you build something the whole darn project into the Nix store. Fine when you have a small project, but with large projects this becomes a significant overhead.
    - ParetoOptimal 4y ago
      > It copies every time you build something the whole darn project into the Nix store. Fine when you have a small project, but with large projects this becomes a significant overhead. Isn't copying the repo to a read only location just inherent to the problem of reproducibility?
      - grumbel 4y ago
        Not necessarily, most build systems allow you to separate source input and build output. So grabbing the source from the current directly is a possibility, if the build script is clean and doesn't do anything weird in the source directory. In Nix you can get that via 'nix develop', which gives you a shell with access to the individual build phases and with a bit of tweaking, allows you to run them from your source directory without copying the source around first (see 'declare -f genericBuild').
baby 4y ago
I’ve heard guix uses scheme, so I’m not sure I understand how it can be friendly (you (see (what (I (mean))))))
Macha 4y ago
Is there an actual tutorial on how to use the nix command? All the official docs for Nix seem to be slightly discouraging it as not ready where they do mention it. It's one where the community is pretty clear don't use nix-env etc. but the tutorials only explain nix-env, with the only details of the new commands being the CLI reference manual which doesn't cover workflows.
- phaer 4y ago
  Yes, my understanding is that the official documentation lags behind community usage, because flakes are still an "experimental" feature as details of the implementation are worked out. For reference documentation, there's "experimental commands" in the manual https://nixos.org/manual/nix/stable/command-ref/experimental-commands.html https://nixos.org/manual/nix/stable/command-ref/experimental...
- barkingcat 4y ago
  I'm finding nix-env to be great! I do not understand why nix offers a command and a package index, but then advises not to use it. If people aren't supposed to use nix-env, why don't nix put a huge deprecated notice on every invocation and delete the nix-env command itself from nix?
  - Macha 4y ago
    I think the problems with nix-env come down to two things: - nix-env -i and nix-env -u will almost certainly eventually do the wrong thing for you if you use them enough (nix-env -iA is ok): https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-packages/ https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... - It's not reproducible as it depends on the state of your nix-channel setup at that time. How much of a problem this is depends on your use case. nix-as-homebrew-replacemnt or nix-as-shared-package-list-across-osx-and-linux users are probably fine with this, as what these users care about is more portability than reproducibility, but nix-as-predictable-dev-environment types will be let down by it. I think the fact that the latter affects different users differently and that the new flake world doesn't offer a "modify your global environment without the tool taking over" option (expecting you to use nixOS or nix-darwin instead) has meant that there's not enough motivation to agree on a replacement that nix-env could tell you to use instead. I guess the eventual replacement will be "nix profile", but while you'll find at least some documentation on "nix develop" and "nix flake", I had to look in the CLI tool docs for this one, which makes me suspect it's even less final than the other two So instead the community will tell you to avoid nix-env, but there's no agreement to have the tool or docs tell you that.
_hl_ 4y ago
> Error messages that tell you absolutely nothing about what went wrong were pretty common. Maybe I'm holding it wrong, but I almost never get useful error messages from Nix (NixOS and NixOps). Almost every error is deep within some module with no trace to the option I set. Just nix barfing its 300-line eval traceback where my own code doesn't even appear.
- geddawm 4y ago
  Nix has a debugger now. You can drop into the frames that are causing problems and inspect the state. Miles easier than looking at the trace manually.
  - benreesman 4y ago
    I last flashed my flake.lock in June, so I might be out of date, but my rigs can’t reliably include the line number in my code that led to the duck-typing fiasco deep in the core of someLanguage.withPackages.fuck.WTF.this. Fix the fucking “—show-trace” thing folks. Seriously.
    - VTimofeenko 4y ago
      Out of all cases when I used --show-trace, I can remember it being useful only once or twice. I gave up and just sprinkled builtins.trace. IIRC debugger comes with nix 2.9 and nixpkgs for 22.05 still has 2.8.x.
  - n8henrie 4y ago
    I was excited to see the debugger flag to nix build the other day, since I'm really struggling cross-compiling an RPi on BTRFS root sd image. Of course running with the debugger flag resulted in an unintelligible error message and no debugger.
  - rtpg 4y ago
    Any link to documentation on how to use it? Would be a godsend for me
- 4y ago
rekado 4y ago
Guix has package transformations, which lets you use different commits or git URIs for a given package definition. It also doesn't require the definition of a package if all you want is an environment to hack on the code in a git repo. People use `manifest.scm` or `guix.scm` for these purposes. Guix System services are in fact all built together, but upgrading individual software or services does not require "roll[ing] back the complete Guix system ". (I want to point out that describing Guix as "a NIH version of Nix" is a symptom of the attitudes that made me almost completely retreat from discussions of software online. It's so grating to deal with dismissive attitudes like that again and again. Sucks all the fun out of hacking.)
civodul 4y ago
Guix channels (not to be confused with Nix channels) let you turn a Git repo into a package collection: https://guix.gnu.org/manual/devel/en/html_node/Channels.html https://guix.gnu.org/manual/devel/en/html_node/Channels.html I guess it serves some of the same purposes as Flakes, and it comes with other bells and whistles such as authentication (which I think is kinda important!). For the rest, your description of Guix is largely incorrect ("has none of that", "you have to roll back the complete Guix system", etc.), but as a Guix hacker I'd be interested in better understanding your experience and perceptions if you'd like to get in touch with us on the mailing lists!
f1refly 4y ago
> Also with Nix you just use regular shell scripts snippets for the building the packages, Guix wants you to do it all in Scheme I'm by no means a good schemer, but I'd still take scheme over shell every time. Shell tends to devolve into something completely unreadable with even moderate complexity while scheme can make even the most complex logic nice to work with. > Guix has none of that, they still treat packages as a separate thing from the software itself I'm not quite sure what you mean with that, but it's sure possible (and easy) to just define a guix repo that points to all your projects repositories and make them available through the guix package manager. Guix repos are just git repos with a few lines of metadata attached. > Easily up or downgrading individual software isn't possible as far as I can tell, you have have to roll back the complete Guix system to do so. It's very easy actually. You declare a package definition as an inferior to a package and can pin that definition to whatever version, commit hash, tag, you want. You basically say "I want the package declared as name X, but I want it while the guix repo is at point Y. That way, the package manager knows what dependencies the package has and provide those with the right versions as well. > NixOS just felt like a more polished and feature rich version of what Guix was doing, which given that Guix is basically a NIH version of Nix, is understandable. On the contrary, guix is more like a more polished and dedicated version of nix. Nix's solution to hard-to-package packages is "We take everything that's needed to build this thing and freeze it in the repository" while guix will not accept anything that doesn't build completly from scratch and can thus be distributed as optional source code. The difference is very important because it allows for better packaging and more flexible versioning of the packages. Using guix, you will never run into a situation where the solution has you staring down at a binary blob and questioning your life choices.

josteink 4y ago

> Doing everything with Scheme just leads to layers of macro spaghetti that I really did not enjoy to dig through. On the flip side, it’s a real language, well understood, with a real specification, working tooling, and community support outside Guix (or in the case of Nix, outside the package manager). As someone who gave up NixOS exactly because of the incomprehensibleness of the Nix language, I know what I would choose. There’s no doubt at all.

grumbel 4y ago
I see nothing especially incomprehensible about Nix, the language itself pretty simple. About the only thing I had a bit of an issue with is that I kept forgetting that functions only take a single argument in Nix. But other than that it is very nice to work with and has all the syntactic sugar you want, string interpolation, sets/map, sane multi-line strings and all that. Syntactic sugar is an area where Scheme has basically nothing to offer, everything needs calls to functions with long names. For most common uses you barely even have to care about the language, as it's just some JSON-like data with shell scripts in between that do the actual work.
- parminya 4y ago
  The language very much generates complaints because it is gives you no real help understanding what argument should be passed to what function and how to get that argument. Error messages are dreadful because there's often a million functions your object has to go through before it produces an error. Dynamic typing and lazy evaluation don't seem to mix. Some kind of compile-time, presumably gradual, type system would really be an incredible improvement, so that type errors were generally eager.
  - pxc 4y ago
    > Dynamic typing and lazy evaluation don't seem to mix. Incidentally, this is one of the things that some of the people involved with the blog post in the OP have set out to fix. A few years ago, Théophane (author of the blog post) started an experiment to add gradual typing to Nix, which eventually became the start of Nickel: https://github.com/tweag/nickel https://github.com/tweag/nickel Today, Nickel development continues at Tweag, but now they have someone else, Yann Hamdaoui, driving the implementation forward. (I assume because he's a domain expert in programming languages.) Producing helpful error messages is one of the major goals of Nickel, as a potential successor language to Nix. All of the language design decisions are documented as GitHub issues on the repo, so if the technical side of this kind of problem is interesting to you, you may enjoy browsing that. It appears that Nickel is very close to a usable state for early experimentation. You might be interested in cloning the repo and messing around with it!
baby 4y ago
Honestly I’ve done enough scheme to understand that I wouldn’t touch anything related with scheme in a million years. People who think otherwise probably don’t understand why people like javascript and python and will never write any product that catches on. The nix language is pretty nice on the other hand. The only thing I’m missing is a language server protocol thing so I can go to definition
- t0astbread 4y ago
  rnix-lsp is a language server for Nix that provides go to definition. I'm using it with the "Nix IDE" extension in VS Code. It doesn't handle imports though afaict, so it's only useful for local definitions.
- axlprose 4y ago
  > People who think otherwise probably don’t understand why people like javascript and python and will never write any product that catches on. Ironically, this has been posted on a popular site written in a dialect of scheme: http://arclanguage.org/ http://arclanguage.org/ https://github.com/arclanguage/anarki https://github.com/arclanguage/anarki
  - baby 4y ago
    how is this ironic? HN was written by one person, and nobody needs to care what language they used to make it work.
  - meltedcapacitor 4y ago
    Where is the irony? HN does not expose scheme to the user. Don't think the parent was saying that it's impossible to write a good program in scheme/lisp, more that scheme as user interface for a software system is a hard sell... which seems anecdotally true.

jyrkesh 4y ago

> Another big thing, Nix has Flakes, which make it trivially to turn all your Git repositories into Nix packages. I have no doubt that this is true, but I still feel dumb about it. I run a Plex server (among a few other workloads) on a NixOS box, and just figuring out how to update the Plex binaries off of the official master branch was a multi-hour back-and-forth endeavor between StackOverflow suggestions and compiler errors. I really do love Nix though. And once I got it working I felt a LITTLE bit smarter, AND it's worked flawlessly for months.

benreesman 4y ago
I’ve said this elsewhere in the thread and might do so again but it bears repeating: use flakes. At first they seem like this weird semi-supported thing, but eventually you realize that Nix is badly broken without them. Flakes aren’t “experimental”. “Experimental” is what happens to your sanity without them.
- yjftsjthsd-h 4y ago
  > Flakes aren’t “experimental”. “Experimental” is what happens to your sanity without them. Okay, I like flakes, I use flakes, I enable flakes without much worry. But. They literally are an experimental feature, and they are still enabled by setting "experimental-features = nix-command flakes" in nix's config.
  - benreesman 4y ago
    I think I was maybe too casual with my language. Flakes are clearly marked experimental in the documentation. But they were a no-brainer a year ago, they’re always “a few months” from being official, they map directly onto users’ intuition around lock files, they enable principled composition of shit that doesn’t live in nixpkgs, the list goes on. Outside of some (hypothetical to me) edge cases, not using them is masochism. Flakes have a standard library (“flake-utils”) and and a pimped out version (“flake-utils-plus”). Making it a weird gymnastics trick for a novice user to even access them is the kind of shit GHC devs say, “no, that’s too user-hostile even for us”. Use flakes.

Smaug123 4y ago

It's not quite true that it's trivial to turn a Git repo into a flake, because flakes don't do submodules, and https://github.com/NixOS/nix/pull/5497 https://github.com/NixOS/nix/pull/5497 has languished :(

grumbel 4y ago
You can fix that by adding '?submodules=1' to the URL. It does get rather annoying when compiling local code, as that turns a simple 'nix build' into: nix build "git+file://$(pwd)?submodules=1" But it will work with submodules. Another mild annoyance related to this is that Flake inputs can't be expressions, this can make it a rather difficult to fetch dependencies that aren't packaged in a way understood by the existing fetch methods.
- microtonal 4y ago
  as that turns a simple 'nix build' into Which reveals another annoying thing about using flakes for development. It copies every time you build something the whole darn project into the Nix store. Fine when you have a small project, but with large projects this becomes a significant overhead.
  - ParetoOptimal 4y ago
    > It copies every time you build something the whole darn project into the Nix store. Fine when you have a small project, but with large projects this becomes a significant overhead. Isn't copying the repo to a read only location just inherent to the problem of reproducibility?
    - grumbel 4y ago
      Not necessarily, most build systems allow you to separate source input and build output. So grabbing the source from the current directly is a possibility, if the build script is clean and doesn't do anything weird in the source directory. In Nix you can get that via 'nix develop', which gives you a shell with access to the individual build phases and with a bit of tweaking, allows you to run them from your source directory without copying the source around first (see 'declare -f genericBuild').

baby 4y ago

I’ve heard guix uses scheme, so I’m not sure I understand how it can be friendly (you (see (what (I (mean))))))

Macha 4y ago

Is there an actual tutorial on how to use the nix command? All the official docs for Nix seem to be slightly discouraging it as not ready where they do mention it. It's one where the community is pretty clear don't use nix-env etc. but the tutorials only explain nix-env, with the only details of the new commands being the CLI reference manual which doesn't cover workflows.

phaer 4y ago
Yes, my understanding is that the official documentation lags behind community usage, because flakes are still an "experimental" feature as details of the implementation are worked out. For reference documentation, there's "experimental commands" in the manual https://nixos.org/manual/nix/stable/command-ref/experimental-commands.html https://nixos.org/manual/nix/stable/command-ref/experimental...
barkingcat 4y ago
I'm finding nix-env to be great! I do not understand why nix offers a command and a package index, but then advises not to use it. If people aren't supposed to use nix-env, why don't nix put a huge deprecated notice on every invocation and delete the nix-env command itself from nix?
- Macha 4y ago
  I think the problems with nix-env come down to two things: - nix-env -i and nix-env -u will almost certainly eventually do the wrong thing for you if you use them enough (nix-env -iA is ok): https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-packages/ https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... - It's not reproducible as it depends on the state of your nix-channel setup at that time. How much of a problem this is depends on your use case. nix-as-homebrew-replacemnt or nix-as-shared-package-list-across-osx-and-linux users are probably fine with this, as what these users care about is more portability than reproducibility, but nix-as-predictable-dev-environment types will be let down by it. I think the fact that the latter affects different users differently and that the new flake world doesn't offer a "modify your global environment without the tool taking over" option (expecting you to use nixOS or nix-darwin instead) has meant that there's not enough motivation to agree on a replacement that nix-env could tell you to use instead. I guess the eventual replacement will be "nix profile", but while you'll find at least some documentation on "nix develop" and "nix flake", I had to look in the CLI tool docs for this one, which makes me suspect it's even less final than the other two So instead the community will tell you to avoid nix-env, but there's no agreement to have the tool or docs tell you that.

_hl_ 4y ago

> Error messages that tell you absolutely nothing about what went wrong were pretty common. Maybe I'm holding it wrong, but I almost never get useful error messages from Nix (NixOS and NixOps). Almost every error is deep within some module with no trace to the option I set. Just nix barfing its 300-line eval traceback where my own code doesn't even appear.

geddawm 4y ago
Nix has a debugger now. You can drop into the frames that are causing problems and inspect the state. Miles easier than looking at the trace manually.
- benreesman 4y ago
  I last flashed my flake.lock in June, so I might be out of date, but my rigs can’t reliably include the line number in my code that led to the duck-typing fiasco deep in the core of someLanguage.withPackages.fuck.WTF.this. Fix the fucking “—show-trace” thing folks. Seriously.
  - VTimofeenko 4y ago
    Out of all cases when I used --show-trace, I can remember it being useful only once or twice. I gave up and just sprinkled builtins.trace. IIRC debugger comes with nix 2.9 and nixpkgs for 22.05 still has 2.8.x.
- n8henrie 4y ago
  I was excited to see the debugger flag to nix build the other day, since I'm really struggling cross-compiling an RPi on BTRFS root sd image. Of course running with the debugger flag resulted in an unintelligible error message and no debugger.
- rtpg 4y ago
  Any link to documentation on how to use it? Would be a godsend for me
4y ago

rekado 4y ago

Guix has package transformations, which lets you use different commits or git URIs for a given package definition. It also doesn't require the definition of a package if all you want is an environment to hack on the code in a git repo. People use `manifest.scm` or `guix.scm` for these purposes. Guix System services are in fact all built together, but upgrading individual software or services does not require "roll[ing] back the complete Guix system ". (I want to point out that describing Guix as "a NIH version of Nix" is a symptom of the attitudes that made me almost completely retreat from discussions of software online. It's so grating to deal with dismissive attitudes like that again and again. Sucks all the fun out of hacking.)

civodul 4y ago

Guix channels (not to be confused with Nix channels) let you turn a Git repo into a package collection: https://guix.gnu.org/manual/devel/en/html_node/Channels.html https://guix.gnu.org/manual/devel/en/html_node/Channels.html I guess it serves some of the same purposes as Flakes, and it comes with other bells and whistles such as authentication (which I think is kinda important!). For the rest, your description of Guix is largely incorrect ("has none of that", "you have to roll back the complete Guix system", etc.), but as a Guix hacker I'd be interested in better understanding your experience and perceptions if you'd like to get in touch with us on the mailing lists!

f1refly 4y ago

> Also with Nix you just use regular shell scripts snippets for the building the packages, Guix wants you to do it all in Scheme I'm by no means a good schemer, but I'd still take scheme over shell every time. Shell tends to devolve into something completely unreadable with even moderate complexity while scheme can make even the most complex logic nice to work with. > Guix has none of that, they still treat packages as a separate thing from the software itself I'm not quite sure what you mean with that, but it's sure possible (and easy) to just define a guix repo that points to all your projects repositories and make them available through the guix package manager. Guix repos are just git repos with a few lines of metadata attached. > Easily up or downgrading individual software isn't possible as far as I can tell, you have have to roll back the complete Guix system to do so. It's very easy actually. You declare a package definition as an inferior to a package and can pin that definition to whatever version, commit hash, tag, you want. You basically say "I want the package declared as name X, but I want it while the guix repo is at point Y. That way, the package manager knows what dependencies the package has and provide those with the right versions as well. > NixOS just felt like a more polished and feature rich version of what Guix was doing, which given that Guix is basically a NIH version of Nix, is understandable. On the contrary, guix is more like a more polished and dedicated version of nix. Nix's solution to hard-to-package packages is "We take everything that's needed to build this thing and freeze it in the repository" while guix will not accept anything that doesn't build completly from scratch and can thus be distributed as optional source code. The difference is very important because it allows for better packaging and more flexible versioning of the packages. Using guix, you will never run into a situation where the solution has you staring down at a binary blob and questioning your life choices.