Taken from the article:<p>> "Strongly typed (with dyamic casting)"
> "while Go is statically typed, it has a strong system for dynamic casting and reflection".<p>This is not even wrong. The <i>whole</i> point to using types is to make strong <i>guarantees</i> about the meaning of programs without even having to run them. Dynamic casting and reflection <i>destroy</i> the usefulness of these guarantees, by virtue of their semantics depending on information only avaluable at runtime. Strong typing with dynamic casting and reflection is like a safe knife whose handle is a blade!<p>> "Really good at concurrent stuff, pretty fast"<p>Give me a break. Concurrency support is all about compartmentalizing the use of resources as much as possible, reducing sharing between the concurrent units of computation (processes, tasks, goroutines, whatever you want to call them) to the bare minimum required for the program as a whole to serve its goal. How does Go's shared memory model help in this regard? This fundamental inadequacy has negative consequences both for correctness (synchronization is a convention, it is not actually enforced) and for performance (Go needs a stop-the-world garbage collector).<p>===<p>Go might have been barely interesting ten or fifteen years ago, but in 2013, this kind of design has to be rejected as mediocre.