C++11 Makes Competitors Go Rusty

Is it just me, or could the author know only Go and Rust from their Wikipedia entries?

I find the concept of a C++ programmer using the ABI as a bullet-point against switching to a different language highly ironic.

I wonder if you are confusing TR1 (which came out several years ago), and C++11.

TR1 was designed to not need compiler extensions (although some parts of type_traits, that AFAIK no-one ever used in the TR1 days, could be improved with compiler support). TR1 added regex and tuple among others. It certainly didn't have rvalue references.

C++11 is the new big standard, which certainly requires large amounts of compiler support.

Compatibility: The new language will have to talk with older languages. Types will have to be translated; memory models will need to be aligned and compilers will need to 'play nice' together. This is not just as the compiled object level but at the ABI level during linking etc. I've spent more time solving issues with memory models in C++ than I have in any other language because C++ has no ABI - I've had patches to MSVC change the memory layout of objects and cause breakage which is just as bad as you get with any sort of language interop scenario.

Performance: This new language is super fast. Great, but it will have to work with existing systems. The interface between the two will slow stuff down a lot... Seeing as C++ has no ABI, there's no non-hacky way to provide a C++ binary shared library that doesn't end up using a very small subset of C++ (for example, no STL, since it's all templated, meaning the code your compiler generates won't interoperate with the code the client's compiler), which means people end up wrapping their C++ code with C APIs.

Build: ... #include is a broken piece of legacy that everyone will be happy to see disappear - give us real modules instead of a compilation model which pastes file contents inside other files. Also, C++ compile times are ridiculously long compared to a modern CFG-based language (that's disregarding the fact that compilers often disagree as to what's valid code because of the extremely complicated syntax of the language).

Debugging: ... Debugging modern code that uses shared_ptr, bind, etc. is such a massive pain in the ass because you end up mixing the code you care about with those plumbing details - "step into " becomes useless. Add the fact that there is no ABI and you find yourself unable to introspect objects at runtime when compiled in release mode (where all the nasty memory issues tend to show up)

Team Training: ... C++ is, as I've been ranting, complicated. I've been using it for a long time, and there's still no language in which I fear making subtle mistakes that'll cause hard-to-diagnose bugs (for example, exceptions are often treated as an anti-pattern because it's so hard not to make such mistakes using them)

Team Embedded Knowledge: ... This is a valid point. I don't think it's worth the price you pay for using C++...

[Ecosystem complaints - tooling, licensing, lifespan] Beyond the fact that tooling for managed languages is often superior to C++ (because of the better-controlled memory layout and execution model), these are valid points.

Startup And Shut-down Sub-Systems: ... This is also broken in C++ - in what order are static objects initialized (definition order inside a cpp file, file sequences are random)? What happens if one wants to refer to another? I know these are solvable issues, but every single one of them requires thought and effort on the programmer's side, and these aren't the sort of issues that a programmer should be wasting his time on.

Paradigm Contamination: ... Yes, writing in a language and writing idiomatically in a language are two different things, but modern, idiomatic C++ is both something I've seen few people who know (compared to out-dated and dangerous practices), and it still requires more effort to keep in mind than, say, writing idiomatic python, or C#, or java.

Brain Strain (the bilingual problem): ... This isn't really an argument - it's speculation. I could say that perhaps the fact that C++ is so varied that different subsets of it end up looking like different languages, and all of them with more details you have to keep in mind to make sure you aren't breaking stuff subtly. Also, being bilingual also provides cognitive advantages, so even that flawed analogy might not be proving the point.

Let us think about the big ideas behind Go: [snip] Well, one can write simple clean C++ and use share_ptr. Just because C++ can be super complex does not mean it has to be. Unless, say, you're writing a DLL (another fun fact: not only can your API not have STL, exceptions also can't cross DLL boundaries), or you're using DLLs written by other poor souls who were consigned to writing DLLs with a C++ API.

This is not to say that C++ has no place in software development (I use it daily at work), but I'm of the opinion that unless you have a really good reason, avoid it like the plague. New languages taking over more niches C++ used to occupy is a good trend.

As a finishing note, one of my favorite articles on the subject of complexity in programming: http://www.joelonsoftware.com/items/2009/09/23.html

> have actually been harmed by the presence of features in the language

I am harmed routinely by too many features. I've been coding C++ for 11 years and I still end up scratching my head when I end up in foreign territory. Even his code at the end of the article which I think is supposed to be illustrating some kind of simplicity looks like a giant hairball of mess to me. I've ended up devolving to using a small subset of C++ features in my code which I know inside out and is sufficient for my needs. Others all seem to do the same but they arrive at a different subset. Java on the other hand seems to be so feature deprived and simplistic (minus generics, but they are almost an anti-feature) that no matter whose code I look at it is extremely obvious what is going on.