As a strong C++ dev and googler (hopefully with some #golang exposure), what's your opinion on @rob_pike post? (goo.gl/xlMi4)The answer deserves much more than my original reply included, so here it goes.
First of all, I found Rob's article quite interesting. Basically, the authors of Go never expected Go to be more widely adopted by Python users than C++ users. In fact, their original goal was to create a replacement for C++ as a systems programming language. The rationale for this is that C++ users like the verbosity and flexibility of the language, with all of its special cases, while Python users like simplicity and switch to Go when they look for the performance bump. This is all reasonable but there is one detail I don't associate with: Rob claims that whoever is excited by the new C++11 features will not move to Go, because liking new C++ features implies that one likes all the flexibility of C++ and will not enjoy Go's simplicity.
Before I explain why, let's look at my personal scenario: I use C++ for personal projects and Python at work. I enjoy using C++ because of its expressivity and the cool hacks that can be implemented (although that generally goes against readability), and I really like Python due to its simplicity and its extensive standard library. But I dislike C++'s corner cases, lack of real modules, verbosity, huge binaries, slow compilation times... and I dislike Python's non-static typing.
So why do I use C++? Most of my personal projects, if not all, are in some way related to NetBSD. NetBSD has support in the base system for C, C++, POSIX shell and, recently, Lua. If I want my projects to be bundled into the NetBSD base system, I need to use one of these languages; that's clear. Of these languages, shell is not scalable for large projects and I don't know Lua enough to implement large pieces of code (but from what I have learned, Lua has its own problems). Writing C is a waste of time due to its lack of support for basic high level data structures (things like, you know, strings and dictionaries) — and these are a must for any medium-large project. And C++, despite all of the problems mentioned above, is a good compromise.
In other words: the reason I chose C++ for things like ATF and Kyua is only because it simplified my work and it was supported by the NetBSD base system. It's relatively easy to write safe code (the RAII pattern is lovely) in C++ and there is an abundant amount of rich data structures in the base library. (This doesn't mean I will stick to C++ forever in Kyua; in fact, I have some ideas in mind to reduce its usage!)
And finally, this is where I can counter Rob's statement: I am excited about the new C++11 features but not because I really like C++. I will enjoy the new features because they simplify a language that is the only real alternative I have in this context.
Confession: In fact, I don't really like C++. I wish there was a better alternative within the NetBSD base system for large projects, but there is none.
