> his biggest surprise was Go is mostly gaining developers from Python and Ruby, not C++
Why is that a surprise? I think it's logical, and Go can be expected to attract developers who are used to garbage collection (Java, Python, Ruby etc.). Not so much C++ developers who prefer to have control and choice (i.e. pay for what you choose, rather than get it handed down forcefully). Rust is a better candidate for attracting more C++ developers than those from Java, Python and Ruby background.
Because it was never the intention. Pike and Thompson, by their own admission, hated C++ and set out to write a better language to replace it. Python and Ruby developers where never on their radar during the whole design phase. It might be logical and obvious in hindsight, but it certainly came as a surprise to the creators of the language.
I see. I guess they misjudged features which C++ developers actually valued as something bad and in need of fixing. I.e. while trying to improve, they removed something that was actually good (such as replacing RAII with GC). And on the other hand not fixing real fundamental problems (such as concurrency safety for example). This probably made the language less attractive as a C++ replacement, but still attractive for those who didn't look to replace C++.
If it wasn't for the Google brand -- with the power to promote Gophercons and hire full team language devs -- there wouldn't be a chance to see Go rise above Nimrod, D et al.
What they do have going for them is:
1) A rather complete standard library (because of many paid full time devs compared to any indie language)
2) An easy familiar syntax
3) A simple (but far from complete or unique to them) concurrency story with Channels/Goroutines.
4) Nice tooling (again due to many paid full time devs -- Java and C++ have better, but most languages have worse).
If you compare RAII and GC, RAII looks better to me practically in every aspect. The only advantage of GC over RAII is perceived simplicity (developers don't need to think about ownership specifics). But the price for it is too high (unpredictability), and that simplicity quickly deteriorates into overblown complexity when people hit problems caused by GC. Pragmatically, RAII is simply better and cleaner, as well as fits better with concurrency safety which implies clarity in memory ownership.
RAII for shared resources also induces cache problems if not implemented with lock free algorithms, which are quite hard to get right without some GC help.
There is also the issue for cyclic data structures and a stop the world effect when destroying big data structures.
Personally, I favour GC with (with/using/defer/scope) than pure RAII and was a bit disappointed that the C+11 GC API proposal was just partially adopted into the standard.
Combining RAII and GC (explicitly choosing what to use for various data) can be an interesting hybrid approach. Looks like Rust does exactly that, allowing you to explicitly define which data is garbage collected (while the rest is handled with standard RAII):
Pike and Thompson were out of touch with what people use C++ for this century. Back in the 90's people used to write practically anything in C++ and Go would have been a suitable replacement for many of those uses, but now if you're starting a new project in C++ it's probably something that needs some degree of manual control over memory, so Go isn't a suitable replacement.
>Pike and Thompson, by their own admission, hated C++ and set out to write a better language to replace it.
Well, they might have hated it, but they didn't understood correctly what its strong points were and why people use it for the projects they use it for. If they did, they'd have made something like Rust.
As it is, they solved problems that mostly people doing backend services in Java/Python/Ruby had.
I didn't actually realise this until it was pointed out; if nothing else, mandatory automatic memory management really hurts its usefulness for a lot of the things that people still use C++ for.
Why is that a surprise? I think it's logical, and Go can be expected to attract developers who are used to garbage collection (Java, Python, Ruby etc.). Not so much C++ developers who prefer to have control and choice (i.e. pay for what you choose, rather than get it handed down forcefully). Rust is a better candidate for attracting more C++ developers than those from Java, Python and Ruby background.