I think the parent comment was pointing out that less and less, there's no real reason to need C++. The performance in safer languages is usually far more than adequate, while requiring less code (less bugs) and blocking entire classes of bugs.

Even Tim Sweeny of Epic (Unreal Engine) said they'd gladly switch languages to improve productivity. And game engines are one of the few places that still do need to eek out as much perf as possible.

In short, something like C++ increasingly has more downs than ups. I like C, I just have seen it used in so many places where it makes the code far more verbose, introduces security holes, and has a near-negligible performance benefit.)

"Best tool for the job" is misleading - some tools are nearly completely better than others. Just like globals and goto: they have uses, but less than more.

I once read a comment that said that C++ is like a very sharp knife. If you know how to use it, it's safer than a dull knife; if you don't, then you need to have your totin' chip taken away.

I like to compare it to the F4U Corsair: anyone but a talented and experienced pilot at the yoke will lead to certain disaster. But the thing is just so powerful and so absurdly versatile that until something decisively and significantly better comes along it remains a mainstay of any halfway decent air force.

A lot of people confuse being the Corsair of programming languages with being the Corvair of programming languages -- "unsafe at any speed". They're full of it. Their ignorance and lack of experience prevents them from seeing the scenarios in which the utility of C++ is absolutely indispensable.

That argument seems rather incorrectly biased. The gist is "C++ is awesome, and if you have any problems, it's because you're not awesome enough".

Tim Sweeny's talk[1] indicates that a majority of their bugs are due to low-level "unsafe" code issues. If the people writing Unreal have those problems, I think it's safe to say that it's a problem with the language. Unless you want to make the argument that Epic doesn't hired "talent and experienced" pilots.

C++ sure has places where it might be needed, but those places are growing less every day. And it's more due to the momentum, not the inherent merits of C++. If, say, Microsoft threw their weight behind a language like, say, Rust, the landscape could change. Or if they really pushed on the CLR to make the type system encompass more things and really beef up codegen, we might get somewhere. (The CLR can already easily slide into low level code, even hand-written assembly; the general codegen and limited memory management options are what kills.) Instead, we'll see more things grafted on to C++ (like recent type inference and lambdas) that make C++ somewhat less painful and further reduce the pressure to switch.

1: http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-...

CLR seems to be getting some new toys past Visual Studio 2013.

There is the new JIT compiler based on Visual C++ backend and more targets besides Windows Phone 8 will be supported for native code deployment.

With C++ you trade a bit better performance for a truckload of complexity, busy work and unsafety. Whether that trade-off is worth it depends on the application, but the area in which this is a good trade-off is getting smaller and smaller. The analogy with the knife doesn't make much sense. A sharp knife is safer because you have to apply less pressure, and muscles are more precise and controlled when applying less pressure. C++ is the opposite.

No all GC enabled languages are like Python.

Have a look at Oberon for example. A systems programming language with GC, used to program a fully working single user desktop system in the mid 90's.

Used at many universities around the world.

Yes it required the use of Assembly for hardware communication, but so do C and C++.