You make it sound like `go install` and `go test` are the only things you're ever going to run in a Go repository. This is blatantly untrue. For example, these

You make it sound like `go install` and `go test` are the only things you're ever going to run in a Go repository. This is blatantly untrue. For example, these are the invocations for the test suite for one of my Go programs: https://github.com/sapcc/limes/blob/364317fa9a25065bcf9384c844927377aad10239/Makefile#L30-L48 https://github.com/sapcc/limes/blob/364317fa9a25065bcf9384c8... Why should I have to enter all of this manually every single time? (And before you argue that gofmt, golint and go vet run in the editor if you've set it up properly: That's true, and that's how I have my editor set up. That part of the test is to catch the external contributors that don't.) > The second reason I dislike using make(1) for Go projects is that it harms portability. A Go project should only require the Go compiler to build successfully. For many of my projects, a Makefile is the main reason why repos work with `go get` at all. I use `make` which prepares all the generated files and non-Go artifacts (typically bundled into `bindata.go`), so that I can commit these in the repo. Then when a user comes along, they can `go get` the application because all the bespoke compilation steps have already been done by me via my Makefile. An example of this: https://github.com/majewsky/alltag/blob/df161b55fa4c7eba0abec82d2cf0df34e49b0ad4/Makefile#L10-L22 https://github.com/majewsky/alltag/blob/df161b55fa4c7eba0abe...