> You can write very fast C++, if you spend a lot tweaking it and hire experience and extremely expensive ($300k/year and up) programmers, but typical C++ isn't

> You can write very fast C++, if you spend a lot tweaking it and hire experience and extremely expensive ($300k/year and up) programmers, but typical C++ isn't any faster than well-written code in other languages. I disagree and so does Andrei Alexandrescu: "The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu Here's the thing about performance. Sometimes you care and sometimes you don't care. When you don't care- you don't care. You can write it in Python and even though it runs 10000 times slower, you still don't care. When you do care a factor of 10000 for Python vs. C++ or a factor of 3-5 (or more) of JVM languages vs. C++ can mean running 5 million servers instead of 1 million servers, or 10 frames per second vs. 60 frames per second, and the success or failure of your business. This is why pretty much all the big players who care about performance use C++ (from games to web at scale). The maintainability of large C++ projects is pretty much field proven and C++ is also evolving and while not quite fixing some of the causes for grief (because it maintains backwards compatibility) it offers new ways of doing things that are safer, more maintainable, and just as fast. The only thing you said that I can slightly identify with is that you need good people in order to build things in C++ (and no, they don't cost $300k/year. I wish.) This is not a con, this is a pro. You want that regardless of language and good people will be expensive. Yes, you can get cheap people to write bad code in any language. EDIT: Another data point. I worked on a huge Python project where performance did turn out to be an issue and it was virtually impossible to find a "critical" part to apply C++ to. It was just slow throughout, it was built over a huge base of meta-programming and Python specific magic. There was simply no single piece you could point to that if written in C++ would make it go significantly faster. My point there is that while it's certainly possible in a well designed system to mix languages while applying fast languages to performance critical portions it's not always possible after the fact. Language choice is an engineering decision and there's no single answer but you have to be very careful with the attitude of just throwing something together in the mistaken hope that it can be fixed later. EDIT2: I could say more to defend C++'s "honour" but it doesn't need me as a champion... The choice of programming languages though is important and we need a way to eliminate some of the FUD. Part of that is through sharing real world successes and failures. Naturally there is some cognitive dissonance happening, that is if I chose language X, therefore I'm smart, therefore language X is the best, therefore other people who chose language Y don't have a clue. Where this turns from religion to data is when we can say share data about the project N years later that is somehow comparable to other projects and people can try to gather some insight from that data. The nice thing about performance is that it has an objective component to it, that is if we look at a certain problem we can get some numbers that we can compare. It's quantifiable. Factors such as development time, maintainability etc. are less quantifiable. Developer salaries, while quantifiable, are also hard to compare but are definitely a factor in making language decisions.