I see that as an obvious mistake. C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. The problem though is that C++ people likely aren't C purists to begin with, or that C purists are too into C. Compounded by those who only drop to C when needed, you begin to see why it failed initially in this segment. I do think it will continue to gain adoption, but linux is such a firm C membership club that it will either be painfully slow, or else require Go to play nicer with C.
> C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution.
I think it has nothing to do with the difference between C and C++ and everything to do with the reasons why people use C and C++: extreme performance, zero-cost abstractions, and integration with native libraries.
I think you are right, and I tried to convey that in my last two sentences but in retrospect worded it poorly. I guess what I was trying to say there is that people who "drop to C"(or for that matter, start in C) for performance reasons or compatibility reasons aren't going to consider a slower and less integrated language. This is probably most people, I'm not sure many people write everything in C regardless of task anymore(such as say, webapps).
I still think the initial part stands. C and C++ are not visually or mentally similar languages. Go is very similar to C in logic, so I'm not sure why it was expected that C++ people would flock to it(unless of course they weren't happy with C++, which brings us back to the first condition in that they were probably only using it for performance).
The Go team rightly point out that C++ is needlessly complicated. That is why I despise C++. (I guess I was spoiled by doing Borland ObjectPascal first, as well)
Go provides most of the benefits of the JVM without being as much of a memory hog. Thus, it makes it a nice replacement for somebody who would rather use Pascal/Modula than C++. (Java originally was seen by me as a Pascal in C++ clothing for Unix)
Go is more like a Modula (Algol???) variant with curly braces.
Mapping interfaces onto a funky function/routine call syntax (an optional parameter in a second set of parens for the "receiver"), and maintaining stack frames around a procedural type reference (closure) after the enclosing scope returns, are about the only new tricks.
