I first learned C++ with Turbo C++ back in 1989, 23 years ago. I have used it professionally since 1996, 17 years ago. I've spent most of my career using C++, and the startup I'm at now uses both C++ and Ruby. The only type of compiler upgrade that I missed in my career was cfront to native (thankfully, but waiting for compliance from compilers is painful). Now that C++11 is out, everyone is claiming that C++ is back—when in reality, it never went away for a lot of people.

Which is too bad. There's almost nothing about the language that makes it a good language. Even the so-called beauty of C++11[1] isn't usable by most practical C++ developers at this point because they are stuck with compilers that still struggle with rational C++98 and C++03 compliance (I'm looking at you, HP-UX aCC). Or maybe they've got something that's older and mostly compliant with C++98/C++03 because you have a hardware partner who only provides something that is compiled with VS2005 and won't sell you the source because you're not a large enough partner for them to give a damn. And gods help you if you have an error related to templates unless you're lucky enough to be using clang or can use an error filter to make the thirty thousand lines of errors readable, even if they aren't directly applicable to the missing semi-colon at the end of your class declaration.

It will be 2015 before most C++ developers can even think of using anything from C++11 in a production environment, if their (almost certainly mandatory) coding standard allows for it. C++ requires coding standards because you really can blow off your leg.[2]

Not only that, features that would be vitally useful in many applications like real introspection continue to be missing for no good reason at all. Multiple inheritance is an absolute blight on the language, and the fact that the `explicit` keyword even exists is problematic (or that constructors are, by default, not virtual).

All of that said, there's a lot of C++ code out there and it's a good enough language for a lot of functionality, even though it's neither a humane language nor a particularly secure language. There's a lot of libraries out there, and they work reasonably well. For a lot of solutions, the problem isn't finding if there's a library to help you do something, but picking a library from a couple dozen implementations and making sure that some other library you depend on doesn't implement the same thing differently…and then making sure that what you pick actually works with the compilers you've chosen or had forced on you.

If you're truly lucky, you work in an environment that lets you do the bits that you must do in C++ without too much issue, and then you can use Python, Ruby, JavaScript, Lua, or something else to drive the higher-performance code with languages that better express business algorithms.

I'd still rather use Ruby for my whole program (when I had time for OSS projects, I even explicitly went with pure Ruby solutions because of compiler issues), but there are places where C++ isn't just the right tool, it's damned near the only viable tool. A full stack developer needs to know it. I'd argue that most devs should learn C++ just so they know how badly a language can be designed and still be useful for developing modern software.[3]

[1] I'm sorry; the C++11 lambda syntax is unbearably ugly.

[2] http://www.stroustrup.com/bs_faq.html#really-say-that He tries to backpedal from this truth. Other languages that are more expressive and IMO more powerful because of the greater expressiveness do not offer the same capability to break things as badly.

[3] Yes, I know. Most of the issues I have with C++ are probably fixed in C++11. It's impressive. It's still a crappy language with even worse compiler support. Far too much of the language is focussed on making me adapt to the compiler, when with modern type inference and a little convention-over-configuration or even hinting, you could probably cut the size of any given C++ program in half (in terms of number of characters) while not losing a thing in terms of optimization.