>>20
Certainly.
First off, it has forced garbage collection. Not only that, but the garbage collector is *terrible*. Not only THAT, but it's not possible to write a good garbage collector for Go because of the language's semantics. They allow "unsafe" raw pointers (in a futile attempt to woo C/C++ developers), which means the collector can't make bindings indirect, and so it can't move memory. That means you can't make a generational copying collector. At least Java forbids raw pointers; its collector is excellent. Moreover, because Java is on a VM, it can perform escape analysis across library boundaries, transforming many allocations into stack allocations. If I'm forced to use GC, I'll take the JVM any day.
Secondly, it gives preferential syntax to its built-in data structures. Sure you can write your own maps, but they won't be anything like the built-in one. This is a horrible design decision. One of the most important and fundamental code optimizations is the ability to write your own data structures. There are a thousand different ways of writing a map, ranging from a red-black or AVL tree to a hash-table, from purely functional to non-atomic mutating, and everything in between. You need to be able to choose based on the problem at hand. This is one thing that C++ does absolutely right; you can just change one typedef and bang, different map implementation. At least in C, there is no syntax for any data structure (aside from arrays), so it's a trivial search-and-replace or changing a couple #defines to transform code that uses one map into another. Good luck trying out a different map from the built-in one in those twenty thousand lines of Go. They literally lock you in; you need to either eschew the built-ins from the start, or live with them forever.
Third of all, Go has no meta-programming or preprocessor. Conditional compilation is an absolute necessity for embedded development, and is extremely useful for debugging purposes. Compile-time code generation should be a fundamental part of any modern language; since they obviously don't care for a template system, even simple substitution macros are a lot better than nothing. Google's tunnel-vision as server developers is most extremely obvious from this point. They are completely blind to the use cases.
That's all I can think of off the top of my head just now. I'm sure there are many more reasons. Go just does not feel right to me; it does not feel like a systems language. That is pure marketing BS in a futile effort to woo C/C++ developers. It is a server applications language, nothing more.