Comment by dudeinsf | Hacker News Reader

Comment by dudeinsf | Hacker News Reader

Spent a year with Guix and writing my own configuration. Definitely much easier to reason about using Lisp syntax over Googling what random function of the DSL you need in Nix, but I ultimately switched to Nix because of it's community and Darwin support. Nix has a large group of folks who just want a sane, declarative way to manage their environments, and to get back to what they were doing. I want to spend the least amount of time managing my tools and when running into problems with Guix, digging for answers or jumping into the REPL just took too long. Lots of devs in the Guix community seem motivated to build and contribute back, which is great if you're looking to spend your time doing that.

I now use Nix to share configuration between my Macbook Pro, NixOS Desktop, VMs in my home lab, etc. Both Guix and Nix are amazing once you've developed your configuration, I'll never go back. I do a simple "./bin/nixos-update" and "./bin/macos-update" and Nix takes care of the rest.

Occasionally I'll pull something upstream that borks my machine; rolling back is so trivial, I'll just check nixpkgs for Issues to see what's going on, where usually I'll find a 1-liner to fix it or I'll wait for the next release.

Links to my configs https://github.com/dustinlyons/guix-config https://github.com/dustinlyons/nixos-config

How does the Nix configuration language compare to Guile?

So I had to write a few functions in both. With Guile, very straight forward using Lisp's powerful "data-as-code, code-as-data" paradigms (the ` operator). A joy really, and writing code just felt like writing Lisp, where one gets to reason about small scope within simple functions.

With Nix, I had to learn how the whole thing works before I could even get started. Nix is not a "normal" language, you're essentially just writing chunks of configuration, organized across different files, building up to one big derivation (as Nix calls it) that gets interpreted.

Nix has syntax on how it expects the configuration to look and what configuration it expects to be defined. You can learn the syntax but it's still confusing (to me) as to what configuration is always expected. And errors can still be cryptic.

FWIW debugging nix expressions is about to get much easier. Master branch of the nix compiler now has a debugger. Hopefully this will be stabilized in the next release cycle.

As a former professional Lisp programmer, I think the Nix language was pretty good. Not the easiest to pick up but I like writing it very much once getting used to it.

The Nix language is basically JSON with functions, similar to Jsonnet. Despite the language being small, it makes it surprisingly easy to deal with large scale configuration. The Nixpkgs repository [1], which contains "over 80,000 software packages," consists of a single large Nix expression spanning thousands of files and somehow manages to be comprehensible.

[1]: https://github.com/NixOS/nixpkgs

What is the process if you would want to attempt to patch something in nixpkgs? Does that happen? Is there a way with your config to do that in an easy way? I think overlays is an attempt to patch it for yourself, but if you would want to prepare a "proper patch"?

nixpkgs has many owners that span across the 80,000+ software packages. When you open a PR against a specific package, the owner is notified via CI that Nix Foundation runs.

To test with your own config, it's easy to instead of importing nixpkgs, to import nixpkgs.applyPatches { patch } with a path to your fix.

And yes, overlays are a great way to quickly override attributes from a package definition, maybe while waiting on others to fix upstream ;)

Thanks! I found there is also possible to define "disabledModules" and then define your own to replace. I think I will try that.

Reply on news.ycombinator.com