Doesn't like gofmt - this is entirely without interest
Broken pkg management - I agree, progress is required here
No inheritance - that's not a bug, it's a feature! This is one of my favourite bold decisions in Go
Missing generics/generic collections - I haven't missed this much, concrete types have mostly been fine, if they can do it elegantly at minimal cost though it'd be a nice addition
net/http is too minimal - disagree strongly, there is cookie support, params/form parsing etc, in fact gorilla is built on top of it. I say this having written code for all the missing bits he mentions. It is not perfect but it's the best std lib http pkg I've seen.
Go is similar but different, I think it pulls a lot of people in because it feels familiar and then is hard to accept because it is in some ways radical by omission rather than by addition of cutting edge features.
No inheritance - true, while it isn't a bug, it was left out in favor of embedding. While embedding isn't the same as inheritance, it gets you functionally close and based on the objections, seems like it would have solved the issue. https://golang.org/doc/effective_go.html#embedding
It's not ready yet though and gopath was not a good idea so I think this criticism is more valid than the others, though probably in a few releases it will be sorted out, right now dep is not in the official tool chain.
I agree with Kenny here. The GOPATH thing I still find annoying, especially because it also forces a fs layout as to where I can store my code that is completely different from everything else I work with, where it just doesn't matter.
dep is making solid progress though. Been using it on a few projects, have been very happy with it so far.
W.r.t generics I find the argument rather weak. I get it that people have come to expect generics and I'd like to at least have some form of that for collection types, like maps b/c it honestly does get a bit redundant. For now it's solvable with codegen but it's a bit jarring when coming from other languages. But I do agree with the Go authors, we need to be very careful with the added complexity this will bring to the language implementation and if that's worth the tradeoff. Much like in Go we prefer clean, simple and obvious things, that should also hold for the implementation itself. Once it's part of the language it'll have to be supported for a long long time.