> "Strongly typed (with dyamic casting)"
> "while Go is statically typed, it has a strong system for dynamic casting and reflection".
This is not even wrong. The whole point to using types is to make strong guarantees about the meaning of programs without even having to run them. Dynamic casting and reflection destroy 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!
> "Really good at concurrent stuff, pretty fast"
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).
===
Go might have been barely interesting ten or fifteen years ago, but in 2013, this kind of design has to be rejected as mediocre.
I don't know why you're being down voted. Your points are completely valid. Without Google's name behind it, Go would not have had all this hype around it.
Fanbois hate it when someone points at the flaws in their favorite language. I still cannot comprehend why. As much as I like Haskell and Standard ML, if someone pointed out their flaws (Haskell: lame module system, needing arcane hacks to selectively introduce strictness; SML: no open sum types, no applicative functors even when generative ones do not make sense), I would not take issue with that. Realizing our tools are not perfect is the first step to improving them.
I have nothing against Google, but their programming languages (at least, the ones that I know of), Dart and Go, are really mediocre and uninspiring. For all their bad reputation, Microsoft at least has F# and is indirectly involved in the development of Haskell. Even Microsoft's take at an objected-oriented language for the uneducated masses, C#, is much better than the Google- and Apple-endorsed alternatives (Java and Objective-C).
> "Strongly typed (with dyamic casting)" > "while Go is statically typed, it has a strong system for dynamic casting and reflection".
This is not even wrong. The whole point to using types is to make strong guarantees about the meaning of programs without even having to run them. Dynamic casting and reflection destroy 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!
> "Really good at concurrent stuff, pretty fast"
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).
===
Go might have been barely interesting ten or fifteen years ago, but in 2013, this kind of design has to be rejected as mediocre.