&gt;The cross compilation is also a thing I guess? I just use docker anyways.<p>Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Go applications usually don&#x27;t have many dependencies so Docker usually doesn&#x27;t buy you much if anything at all.<p>&gt;But no... I mean... I can get a lot of editors to do a better job of formatting.<p>I&#x27;ve never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc...<p>&gt;Go get provides no realistic versioning other than &quot;this is what I grabbed RIGHT NOW<p>The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. I agree creating&#x2F;updating vendored dependencies can be tricky depending on the tool you use and having a Go workspace per project is slightly cumbersome (though no less cumbersome than say virtualenv), but even before Go &quot;officially&quot; supported vendoring, going from zero to development is literally just `git clone` and `godep restore`. Go projects do not decay if you&#x27;ve vendored your dependencies.<p>&gt;so crazy that the ecosystem got a basic race detector before a basic interactive execution tool...<p>Am I crazy that I prefer having a race detector over a REPL? There were plenty of REPL projects that never gained traction because you can develop pretty easily without them. I usually jump into the playground[0] if I need to test something. This has the added advantage of being sharable after I write it, too.<p>[0]: <a href="https:&#x2F;&#x2F;play.golang.org" rel="nofollow">https:&#x2F;&#x2F;play.golang.org</a>