Comment by gmfawcett | Hacker News Reader

Comment by gmfawcett | Hacker News Reader

Parent Full thread

I've been having great success (and fun!) recently, using Nix to manage the build for an application that I wrote in D a while back. The app builds reliably on a particular DMD version (one that's not already bundled in NixPkgs), and with third-party dependencies pinned at certain revisions. I'd like to make it easy to re-build the whole app, from any machine, with exactly that configuration and with a minimum of fuss. Nix seemed like a great way of coordinating all of that.

After the initial learning curve of the Nix expression language, and how the parts of Nix interact, I was able to write ~25 lines of Nix script that will run the whole thing from scratch: find and deploy the right DMD version, download the right dependencies, and build and install the application.

After a build, I can "copy the closure" of the application to as many other machines as I want, with no rebuilding needed. This guarantees that all dependencies (down to libc) are identical on all machines -- even if the machines already have other versions of those libraries installed. I'm very pleased with the results.

So: there's a learning curve to Nix; but beyond that, things get better, and personally I'm finding the return on time-invested to be very good. If you're interested in building your own software with Nix, I strongly recommend reading the "Nix Pills" articles a few times and doing experiments as you go -- many things didn't click for me at first, but the articles helped things fall into place.

https://nixos.org/nixos/nix-pills/index.html

I've had a lot of problems using Nix in the past. Not least of which is that it's terribly hard to search for anything because of the name--not only is the name generic ("nix package manager" -> "Congress nixes aid package...", "nix" -> "*nix", etc), but search engines have a terribly hard time figuring out what nix project I'm inquiring about ("nix package manager", "nix expression language", "NixOS", specific Nix derivations, etc).

Another problem is that the documentation for individual functions is nonexistant. If you want to know how a particular function works, you have to go to the nixpkgs repo in github and try to guess about where the function's definition would live in the massive directory structure, and once you find the definition you care about, you have to read the source code (in Nix expression language--if you're not well acquainted, good luck: the docs are pretty terse and hard to Google for as previously mentioned) which likely references other functions, and since imports don't seem to correspond with the directory structure, you're back to guessing where the symbol you're looking for actually lives. The problem is exacerbated by the dynamically-typed nature of the expression language; other dynamically typed languages at least tell you what type of arguments they expect, but since these definitions aren't annotated at all, you're left guessing. Documentation would do wonders for the project, especially if it's autogenerated like other languages and put in an HTML format so we aren't left hunting around the nixpkgs repo.

What Nix strives to be seems promising, but it's really hard to even evaluate the core ideas for all of the usability issues.

I agree that documentation is a struggle, esp. in the nixpkgs repository. Ideally the maintainers would insist on a "pedantic" level of documentation to help newcomers to onboard themselves.

The Nix Pills series was very helpful, and I like the pedagogical approach he takes there. The Nix documentation itself feels overly dry and academic (which perhaps makes sense given the author's background). I think the world is ripe for a good "Real World Nix" book to lay out an easier path.

Searching for "nixpkgs" instead of "nix" often provides much better results.

There's a lot of effort going into making documentation better. Recently we also got function documentation: https://nixos.org/nixpkgs/manual/#chap-functions

That's great to hear! Hopefully all of my criticism will be invalid very soon (if not already)!

"nixos" might save some trouble?

I've sometimes struggled with this problem with "go" (=> "golang")

naming big projects something common should be a no-no and it's a pet peeve for most of everyone. for something with a very limited scope it's probably less annoying

> “nixos” might save some trouble

Except I’m often looking up something about the Nix package manager or the Nix expression language or some particular Nix formula or other detail.

> golang

This isn’t a problem for me. “golang <question>” works reliably. “Nix expression language <question>” rarely works.

"Nixlang" would be a good convention to start.

"nixos <question>" usually works, even for questions that aren't strictly speaking about NixOS.

Reply on news.ycombinator.com