Speed of compilation, not necessarily speed of compiled code. Missing generics: deadly. Passing around just interfaces? At times clearly not sufficient. Their idea of closures? Looks messy to me. Having a special syntax just for threading stuff? Totally beyond lame!

Golang is absolutely not a replacement for c or c++. It's a better replacement for the other languages out there requiring a VM to run anything. In short golang is better at cross platform than these other platforms and is IMHO good for writing good tooling. One of my colleagues said that golang now is sort of like java was in the old, old days. Making the same mistakes and needing necessary features added to become truly productive.

In my opinion ternary stuff is short handed eye candy and not a great reason to discount a language.

c++'s collections and <algorithm> fundamentally and utterly thrash anything golang claims to have, not to mention the whole stupidity around building garbage collection into a language that wants to be low level.

> In my opinion ternary stuff is short handed eye candy

Granted

> not a great reason to discount a language

The ternary quote exemplifies an attitude at the heart of the language designer's priorities. That is, the lack of ternary is, in fact, much more than a lack of ternary.

> special syntax for threading

You mean the word go?

coroutines aren't threads, fwiw

The main rationale for the lack of ternary, "We don't do control flow with symbols" should also disallow this:

    t && a() || b()

Admittedly tho, nested ternaries are tedious to parse by eye.

They're nothing against nested applications of the above, though. :-)

    t && a() || (u && b() || c())

Personally, I enjoy Rust's choice of letting `if` be an expression.

> I enjoy Rust's choice

As a Scala user, I agree it really is the best

   val a = if (t) a() else b()