> 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.

> 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 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.