The reader may mentally replace my use of the word "freaking" with other choice terms at his or her discretion.

However, there are concepts in Go and Rust that are salient and stand on their own: typeclasses in Go and Rust (concepts, unfortunately, were left out of C++11), rust making std::unique_ptr<> a language feature and support for pattern matching, etc...

While I like support for atomics, memory model, etc.. in C++11, concurrency is still a library in C++. Go and Rust take different approaches to concurrency, but they do make it a _language_ feature which is substantially different.

In short, I hate to bible-thump Paul Graham's article, but this article does remind me of the "blub paradox".

tl;dr I like C++11, but I am glad there are other options (most importantly, Go, and Rust) being developed for userland systems programming.

About half of his points are general gripes about software development, regardless of language(s): license infections, learning new languages, writing languages with the wrong idioms, runtime versioning issues, wah wah wah this all reads like somebody throwing up arguments just to try and distract readers.

His complaint (read:strawman) about interoperability and performance is really misleading. His 'Compatibility' section is not unfair, but all of those problems are faced by programmers dealing with system libraries anyways. Tell me more about the C++ bindings to C libraries and how they are never used in production.

His complaint about 'Performance' is similar FUD. Jesus, dude--if you agree on a calling convention, I can probably get my Brainfuck program to compile and interop with your C library. The computer really doesn't give two shits what language caused the stack pointer to move--it doesn't matter. This isn't a valid complaint.

His lambda is dumb. He didn't do anything there that couldn't have been done with a function pointer, C-style. If he was trying to show why C++11 lambdas are cool, he failed.

(and his code looked like garbage, as others here have mentioned... elegant my ass. No comments, ugly use of operators, namespacing--beautiful C++ this ain't.)

EDIT: Found this, same author I think ( http://nerds-central.blogspot.com/2012/01/sql-failed-experim... ). SQL is a distraction--quick, somebody warn Oracle that they'll be out of business!

Maybe the poor person is just getting lonely in that ivory tower?

C++/Tr1 has also solved many of the same problems without needing a new compiler

Not true. While many of the boost/tr1/c++0x features are introduced via new headers, there are many compiler-level changes, and that's why you need to use the latest versions of clang/g++/msvc/icc to take advantage of them. Things like r-value references just can't be done without a "new" compiler.

My other nitpick is his code sample: I've been write C++ for years but I must say his code sample made my eyes bleed. It's rather far from being demonstrative proof that C++ is elegant and need not be replaced. He should have just imported all the namespaces and been done with it, for starters, in this trivial sample.

But, there is a valid argument for using a newer language that has nothing to do with the language itself: the ancient include, compile and link process. Having to do the #ifndef/#define/#endif dance in every header file I write is a reminder of this fact. That hack exists because 40 years ago, there was no concept of package management. I feel the same way when I get linker errors that require me to unmangle my class names to figure out what's visible where.

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

That's quite a bit of an oversimplification. Goroutines and channels are two big ideas in Go, and the author pretty much ignored those completely.

If you aren't sufficiently familiar with either language to know that neither of them is particularly object oriented, at least in the traditional sense, then you probably shouldn't be writing about them.

If you want a less complicated language than C++11, other than some low-hanging white noise inherited from C, you'll probably have to give up safety, convenience, performance, or exceptions.

Really, how can a tech person think this is a good idea of publishing content? Please fix it.

I know it's personal preference (but frankly, so is the article's position) but that C++11 code looks terrifying to me, I'm still guessing at what several of the pieces of code do. A python programmer looked at my go-code and very easily deduced what it was doing and made good suggestions immediately.

edit: s/VM/GC

So it's cruel, but I usually secretly assume that people who keenly advocate C++ are just poseurs.

Anybody who has actually gone through the whole process of making a program in C++ and fixing enough of the bugs in it that somebody can put it in a box and sell it in the shops, is appropriately circumspect in their recommendations, because they know just how appallingly awful it can get.

So awful, that you'd give up on exceptions, DLLs, new & delete, templates, STL, auto-registering static globals, and all that kind of stuff - because it's actually EASIER to give up all those time-saving modern conveniences, than it is to pick up the pieces after they've been overused.

But nobody believes it until it's happened to them. It just sounds too implausible...