Wrong. I can do with C++ the same design flexibility, including "dynamic" programming ala Java (that's what C++ was before templates) or dynamic programming ala Objective-C.
You can not, with C++, add functions to classes at runtime like you can with Objective-C. You can not, with C++, change the access properties of a particular class instantiation (ie change a method from public to private) at runtime like you can with Java.
You're clearly a C++-centric programmer who fails to understand that the more tools in your belt, the better. Every language has its use. C++ is an awesome language, for specific purposes, just like Java is (for specific purposes), same with Python, and Ruby, and many other languages.
No language is without its faults either.
That doesn't mean anything. Neither is Java. And neither is obj-c. Yet they're both languages that can be compiled to machine code, are dynamically bound, and are capable of providing runtime reflection. It's all about how it's implemented and the runtime.
Your queue class is of no relation to Gochannels whatsoever. You're omitting the Goroutines, which you simply can not ignore. They do not equate to simple threads. Take a look at the Go channel source and you'll understand better what they're actually doing.
not enough to justify a shift to Go.
Runtime reflection, true closures (something not offered any very many other compiled languages), array slices, and a built in parallel programming paradigm certainly justify at least giving it a thought for a very select category of problems.
I'm up for considering anything if it will save time / money / hassle. If it doesn't, oh well, move on to the next tool. Whatever fits!
I should also mention that I'm no Google or Go fanboy. I'm actually a C++ compiler developer by trade so I've no beef with C++ either. In fact I love C++. I love many languages. My thesis was written in D, for example. I've also written commercial applications in Python, Ruby, Erlang, etc, etc.
For me, the jury is still out on Go. I'm not convinced the world needs YAL (yet another language), but I'm open to the idea. If they find a niche for it, great.