Go’s alias proposal and all my concerns of Google controlling Go
The author mentions Go&#x27;s vendor&#x2F; implementation, and I just have to comment about my issues with it (I am filled with the rage of a thousand suns each time I have to deal with vendor&#x2F;). I hope this will serve as an example to other language designers to understand why you should always listen to your community. [ Disclaimer: I am a maintainer of runC and have been contributing to Docker and other Go projects for almost 3 years. ]<p>Go didn&#x27;t have vendoring support in the old days, so the solution that people came up with was to hack with the GOPATH. The idea is quite ingenious, you just have to create a directory in your project of the form vendor&#x2F;src&#x2F;... and the set GOPATH=vendor:$GOPATH. Now, it&#x27;s a hack around the fact that Go tries to take control of your filesystem (something that I&#x27;m still bitter about, and have near-daily issues with) but it&#x27;s a fairly good one.<p>There are several benefits to this method that are quite crucial to point out:<p>1. It doesn&#x27;t require any source code changes to implement. It&#x27;s entirely a build system trick. It also makes the version tagging completely separate from the source code. Luckily this is true for the new vendor&#x2F; implementation. But note that this is actually a <i>complaint</i> people have about vendoring. At least this brokenness is maintained... Lovely.<p>2. You can turn off the vendoring by no longer changing your GOPATH. Or you could point your GOPATH to somewhere else.<p>3. Go&#x27;s importing of the package path is unchanged by vendoring (look at the output of `go list -f &#x27;{{ .PkgPath }}&#x27;` to see what I mean). This may seem like a trivial thing to point out but it has an impact on building in certain contexts, as well as users of the reflect package.<p>4. It worked with every version of the Go compiler (even gcc-go).<p>There is also a few downsides (though you could see them as upsides). The main one is:<p>5. All of the vendoring is done globally. This means that if you pin a version of a repository, and one of your dependencies also uses that repository they will both use the same version. This could cause issues, but also ensures that you <i>know</i> what version of the code you&#x27;re running.<p>But the solution that Go went with (where vendor&#x2F; becomes a magical directory within every project and changes how package imports are resolved) doesn&#x27;t fix all of the same problems. Namely, it breaks points (2), (3), and (4). (2) is hard to do (you have to manually delete the vendor&#x2F; directories), (3) is just simply not possible to fix and (4) is a fun exercise to try to hack around (trust me, I&#x27;ve tried) but because (3) is broken it&#x27;s not possible [ Did I mention that Go _really_ hates symlinks? ].<p>Now, you could argue that it fixes (5) (but the GOPATH trick could&#x27;ve fixed it too). So really the solution Go went with was <i>worse</i> than the solution the community came up with. And it was incompatible with the GOPATH trick (fixing (4) involves trying to convert the vendor&#x2F; to a GOPATH -- it only works sometimes but because the trick involves symlinks good luck with that).<p>And now Go is going to work on packaging. I can&#x27;t wait to see how they break it. I really regret that the containerisation community went with Go as their language of choice.