The only area I would say Go is "good" for is web services. It's really a pretty mediocre language for anything else.
The type system is kind of horrendous, there's no clean way of generic programming, etc. It's really not good for many things, least of all robotics.
If you want to get into Go, I recommend writing a web server. It shows you the good parts of Go, and where it's useful.
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.