| > but that is so hard to setup! And sadly, to use. Nix is a great idea but it could do a lot to help itself out if it ever wants to become more than niche: 1. Use a more approachable package definition language; Starlark (https://github.com/google/starlark-go) or Lua would probably be great choices. 2. Make it reasonable to figure out what the "type" of a package dependency is so we can figure out how to use it and/or find its source code 3. Document package definitions. We document source code in typed languages; Nix expression language is untyped and generally less readable--why not document it? 4. Nix tools have a `--help` flag that only ever errors with "cannot find manpage". This is just user-hostile. 5. Using almost-JSON for the derivation syntax, but then providing a "pretty printer" that keeps everything on one line but with a few more space characters. 6. Horrible build output--everything for every build step (megabytes of useless gcc warnings) gets dumped to the screen. Contrast that with Bazel and company which only print errors. Plus a long tail of other things I'm forgetting. |
I stopped at the point that I had to keep track of an enourmous build.nix file in all my project directories that did a lot of magic if I wanted to use Nix for Go or JS package management.
I also failed completely to search and install executable packages from npm and other minor things I tried.
I did that after going through the complete Nix tutorial and managing to understand pretty much everything and love it.