Different people have different requirements. It makes no sense to declare some tool to be THE STANDARD(TM) if it's of no use for a large proportion of their users.

The way $GOPATH works and dependencies are managed is well-documented. Everybody is free to develop their own tooling. Right now, many people flock towards godep, but that might change in the future. Also, since this is only relevant during development and for compilation, getting it right is not as important as if you had to deploy every single one of your dependencies. With Go, you get one binary, and that's what you deploy.

And there are people like me who think that the programming language tooling shouldn't have to be tracking dependencies. If, for no other reason, than it is common to use multiple languages for a single project, and then a language-agnostic method should be used.

I've leaned towards just having everything it our DVCS (git in our case). External libraries are handled using git subtree.

It is also using a defined way to handle dependencies. I have no problem with that either.

So there is a protocol that is standard, but not the tool which implements it? That is not what I understood after I've read the article. But that would definitely mean it's actually not bad to have different tools.

There must be some standard, though. If you have neither a defined protocol, nor a defined tool, then you have a broken community. That you need to support different package managers for different Linux distros is one of the reasons people don't support Linux for their tools, and I personally would even argue that it is one of the reasons languages like Ruby, Python and Go need to solve that themselves.

It's only an issue for where source code is put, not binaries or shared libs. All Go programs are statically linked, so end-users of a program don't care at all about dependancies. The only people that will care about it are those that want to build the binary themselves.

Also, if you are unaware, Go has great cross-platform building. I can generate the executables for all platforms/architectures Go supports from my single dev machine.

I didn't get the sense they were celebrating their lack of care, or that they chose not to care. (They didn't create Google's build system.) They were simply stating the reality.

What Python fiasco?

I'd guess he's talking about virtualenv + pip moving into the Python core with 3.3.

...I don't remember reaction to that really qualifying as a fiasco, but I could just not have been paying attention at the time.