I was expecting this: Taming the âstatâ storm with a loader cache â 2021 â Blog â GNUÂ Guix to be mentioned, but it wasnât.
As long as Guix uses Lisp (or whatever sub-sub-sub-variant) itâs basically not an option for me, the main reason being the principle of least power. I want the packaging language to be low-powered and focused on packaging.
That said, where can I find a Guix equivalent example of a declaration of a reproducible Nix development shell, for comparison? I found plenty of guix shell PACKAGE examples, but thatâs not reproducible.
I made a long, rambling video about why people should be interested in NixOS a while back (https://www.youtube.com/watch?v=17-TRCpDizA) and within it, I tried to make the case for not trying to get rid of the âdirty shellâ that does much of the grunt work inside package building.
The rationalization was mostly this: itâs awfully temptng to want to use a single language to do âit all.â But then you have to document the resulting framework you build, and if thereâs one thing that Nix hasnât been especially good at, itâs documenting things. This of course isnât really a binary sort of thing; mkDerivationâs phases are a framework even though theyâre assumed to be written in shell (and they arenât documented spectacularly). But when I first started to learn Nix, at least I could stare at the bits of shell in a package definition, and have some idea of what was going on, because Iâm familiar enough with shell to be able to read it and make sense out of it. I donât think the same would have been true had I needed to go read nix (or guile, for that matter) code that did the same thing; I would have gotten lost in trying to wrap my head around the hundreds of little native functions that would have replaced the shell code. I think eelco got it pretty right here.
Great video, btw. A bit of a hidden gem imo. It captures the best reasons to use NixOS, which are about how using it can feel good, what it makes it surprisingly easy in some ways, and how it encourages people who might otherwise run their computers in a haphazard way to accomplish satisfying things.
Personally I donât mind any syntax. For me the only important things are:
- Size of the project / community
- Future of the project (funding)
- Features
- Problems
Iâd love to see honest comparison by someone who used Guix and NixOS for months (not just days). But such person will be difficult to findâŚ
In the last couple of months, Iâve read/heard multiple very negative/opinionated pieces (that Iâd describe as attacks) from Guix to Nix/NixOS. I donât understand the point. I donât see such behaviour for example between Gnome and KDE groups that can be described similarly to Guix and Nix - two open-source projects that are very different but solving the same need. In the contrary, I know that Gnome and KDE often work together and on Linux/open-source conferences you can see their booths next to each other.
Iâd prefer to learn from each other rather than reading that and I trully hope that Nix community wonât reply in the same way since such posts discourage me to even try Guix.
Honestly, build system specific, clearly documented/maintained builders that donât require the user to do much shell scripting would be wonderful. And it almost exists for nix, too, itâd just take a big nixpkgs manual refactor and some more deliberate API design.
I just know from the bazel/buildstream world that it is clearly not so simple to get it right without escape hatches, and we definitely donât have the maintainer attention to have something like that. Itâd seriously surprise me if guixâ implementation was comprehensive enough to meet the demands of all the diverging, partly broken build systems out there without a need for some bash leakage.
I like the Nix/NixOS approach in building packages. Itâs simple and pragmatic.
The only things I found interesting in the post were signing packages (I wonder how to do that reproducibly) and Grafts that might help with large updates.
And the rest - If I ask ChatGPT to write a post about issues with open-source and functional programming, It will give me something similar - open-source is often not fully documented and lazy/functional approach is difficult to debug and infinity recursion can happen. And I know Scheme and Clojure and they have the same problem.
Nix also doesnât have an equivalent to
guix pack.
We have nix bundle, it may not be as developed as guix pack but I am able to bundle emacs and launch it.
Thereâs toArx toRPM toDEB toDockerImage toBuildDerivation toReport
guix = LISP = hard pass
There are way too many parenthesis to keep track off in that language. Had to use it for a short stint of a few months and it completely turned me off of the language. The language belongs in the graveyard together with COBOL.
In 2013 LISP was already not popular The RedMonk Programming Language Rankings: January 2013 â tecosystems
I donât fault its creator for probably picking the language they were most comfortable with and creating a great project, but I simply cannot use it.
Besides that, yes, nix is flawed (but what isnât) and the documentation has sucked for (from what I can tell) 20 years, the tooling is way behind many other languages, the way nixpkgs is managed is far from optimal, flakes is in some kind of limbo state, and more things that the author pointed out, but Iâd use it over guix any day. I least I got it to run 
guix = LISP = hard pass
There are way too many parenthesis to keep track off in that language. Had to use it for a short stint of a few months and it completely turned me off of the language. The language belongs in the graveyard together with COBOL.
Iâm guessing that you did not use Parinfer or Paredit in your ill-fated LISP adventure! These tools take care of all the parentheses for you, either with keyboard commands (Paredit) or interactively as you type (Parinfer), making it very comfortable. I donât generally find Nix files difficult to edit, as the packages I deal with are fairly short, but whenever I am writing a substantial amount of code I appreciate the navigational features of the âstructural editingâ that Emacs+Paredit offer.
In 2013 LISP was already not popular The RedMonk Programming Language Rankings: January 2013 â tecosystems
The earlier LISPs like Scheme and ANSI Common Lisp arenât very popular, but Clojure is a LISP dialect too, and itâs solidly at the top right of the graph you linked even as far back as 2013. In Stack Overflowâs 2021 Developer Survey, Clojure was the second âmost lovedâ language on the list!
Absolutely. Clojure is my personal choice for dynamic language. In my opinion Nix is much closer to Clojure than Haskell and it would benefit from LISP syntax since LISP is the best language for DSL.
Btw. when I write Clojure, I donât want get help with Paredit - I just want help with indentation and I want to see red squiggly line when something is wrong. In other words you just need to get used to brackets and enjoy homoiconicity (code as data).