Well, it has `go get foo` which I'd consider a kind of installer/package manager. That's what I'm referring to since I've seen a good chunk of Go software distributed this way. The README usually says "install Go, then run `go get foo`".
That's fair - i just make the distinction because there's a difference, imo.
In the case of `go get`, there is no preconfigured package, it's akin to a pull and make. Because of that, `go get` tends to be targeted at Go developers. Unlike Python/Ruby/etc, typically only Go developers have the Go compiler at hand.
I mean, i'm in a similar camp with the OP (that you replied to), i don't like installing a runtime just for a specific package. But i typically look at projects that use Ruby as targeted for Ruby developers - not me.
Go is slightly different though, because the compiler is mainly for developers. You don't have to know what Go is to run a "Go binary". So, it's worth an asterisk. That's all i meant :)
Go get is a thin wrapper around git/hg/cvs/whatever. It's supposed to be used by developers, not end users. Note that your link is titled "How to write Go code". For distribution to end users just do whatever you'd do for a program written in C/C++/Java/Erlang/whatever. No need to rub your favorite programming language into your users' face constantly.
But yeah, there's a bunch of Go programmers (presumably those coming from Python or Ruby) that don't really seem to get that you don't need to put source code and a compiler onto your production servers.
Edit: in fact https://golang.org/doc/code.html refers to this as "Remote packages".