@zimbatm, thanks for your PR! By analyzing the history of the files in this pull request, we identified @lethalman, @wkennington and @kamilchm to be potential reviewers.

I was also wondering about renaming buildGoPackage to buildGoApplication like https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/python-packages.nix#L36 if we want to treat it as a convention.

Yeah maybe. I'm not convinced the naming for build<lang>Application is really good, the "application" term is way overloaded. But consistency is good.

I'll merge this PR for now and we can consider the naming bit later on.

The application term was the only thing stopping me from making PR :/ I feel it awkward too but I couldn't find a better name.
Although the rename idea could be just because I wrongly associate buildGoPackage with a Go source package but instead it should be understand only as Nix package built from Go source.

Yeah same thinking here. Also how did we go from mkDerivation to build<lang>Package? It would be nice to define a unified taxonomy that clearly indicated what is what.

In my mind there are two broad kind of derivations: those that are designed to be installed using nix-env and the others.

For the first category we care about:

• name = "${pname}-${version}"; for easy package discovery and upgrade (maybe with variations for multiple-output derivations)
• having all the meta info in place for package search
• following a subset of the FHS to avoid polluting the merged profile tree too much (we should add a check for this by the way)
• being referenced in the top-level
  This first category maps better to the traditional "package" term that we see in other distributions.

For the second category:

• not referenced in the top-level
• that's about it

Libraries sit a bit in between both depending on how they are being used. nixpkgs used to host a lot of libraries intended to be used by the user, like the stackage layers. Nowadays I think we decided to focus on shipping packages and solve the library problems a bit differently, using <lang>2nix conversion tools or external library repositories. Having the <lang> version in the derivation name is mostly useful for the user and making debugging quicker (in case of version mismatches).