The lack of generic support is really terrible. What you have to do instead (cast things to {}interface) is like casting things to Object and then hoping they have the right methods in Java, or passing things around as void* in C++ and then casting them. It's basically the same type safety as a 100% dynamically typed language (i.e. almost none), but with a much uglier syntax.
Many features are built-in, non-extensible language directives. Take the `range` operator. `range` only supports built-in types like maps, slices, and chans. You want to range over a tree? Too bad. Want to range over a graph? Too bad. Want to range over a queue or a linked list? Hmm, well too bad, or maybe wrap the queue or LL with a chan, write a helper function, range over that, and watch your performance go to shit.
And for embedded programming tasks, like robotics, Go simply doesn't have the right primitives. There isn't a way to perform unsafe operations or pointer arithmetic (necessary for embedded programming), so you have to use cgo.
You also lose a lot of language features if you don't have a heap. No chans, no maps, etc.
Considering that Go's claim to fame is its suite of useful language features (like goroutines and easy-to-use chans) and standard library (with good web tools), neither of which are usable in most embedded contexts, and certainly not in real-time contexts, any advantages go might have kind of fly out the window.