I disagree. The experimental vendoring mechanism introduced in Go 1.5 is simple but powerful. In fact, it's very similar to what Node.js does with the nested node_modules directories. The Go team has provided the fundamental mechanism. Now, the community can provide the tooling to manage the packages and the related metadata (like npm in Node.js or pip in Python, but hopefully without the warts…).
My initial thought as an author of "traditional" package manager http://gonuts.io was like your. But then I understand that there is no dependency conflicts. Libraries A and B vendor library C, maybe even different versions C1 and C2 of it. Then your project uses A and B and knows nothing about C. As along as libraries don't do anything stupid like modifying http.DefaultClient, everything is fine.
Re:Go 1.5's vendor/ experiment
by justthistime_ on Friday July 10, 2015 @09:27AM
(#9863788)
Looks like they are trying to exhaust all possible bad ideas, before picking the solution that works.
I expect that they don't even know what works yet, because NIH and "it didn't exist in the 1970ies".
Now, they release this half-baked solution which has no true advantages over the existing vendoring tools other than keeping our import path the same in your source file (which just makes things more confusing imho). No solution for dealing with dependency conflicts, not even tools to detect and manage them other than the compiler itself.
On top of that there's even more "magic keywords" that you need to learn which causes stuff not to behave as you expect, just like the magic comments.
I understand it is also a consequence of having a v1.0 and a backwards-compatibility guarantee, but nearly all features added after 1.0 seem to be added with as minimal effort as needed to get something working, which is not a good thing. It all feels tacked on, the easy way, and not thought out.