This is a useful vignette, but I wanna pick at it a bit because at least sometimes, I don't see things going this way with me.
> oh, so I need to install knit of course. Prebuilt binaries from the internet? Ha ha, no, better to build it
Do you really see most devs thinking this? I don't, even though I'm someone who would build it myself.
> Oh it's in Go, so I need to install Go? Ah, a different package that does the same thing ...
I don't understand what the problem would be here. I maintain several out-of-tree Go packages for Nix for private use and all of them are trivial because Go packages are super easy to build. Are there really many devs out there who are so hesitant to build Go projects, of packages in all languages?
With C and autotools you may already have the toolchain installed, but it's generally harder to build than Go packages.
That way, there's very few prerequisites for a new dev to install (plus you have consistent build/test/run targets for all projects).
If someone wants to manage tools themselves (e.g, the no prebuilt binaries example), they can do that, then skip the Makefile entirely.
* there are fully static prebuilt binaries for a wide variety of platforms (including Windows, where I think it is actually more complicated to install Make than Knit).
* Knit can generate a shell script or Makefile for the build, so these can be used for users who don't want to do development but just want to build from source.
* It is easy to build Knit from source (thanks to Go). Yes you need a Go toolchain, but once you have that it is just `go install github.com/zyedidia/knit/cmd/knit@latest`.
Ah, this package looks nice, I'll have a look. What's a Knitfile? Oh, that looks quite cool; oh, so I need to install knit of course. Prebuilt binaries from the internet? Ha ha, no, better to build it. Oh it's in Go, so I need to install Go? Ah, a different package that does the same thing ...