The C++ bashing season is back (2009)

So without a strong revenue, it is almost impossible to provide alternatives, hence the status quo doesn't change.

C++ got into this position due to people like me, that were considered hipster back then, by going with that slow molass, full of portability issues trying to implement parts of C++ARM, instead of C.

I did it, because sadly the vendors of the alternatives mentioned by Animats didn't managed to keep their languages up to what the OS vendors were putting on their SDKs.

So stuck between C and C++, at least C++ was already a better alternative than writing plain unsafe C code.

Now, Rust macros? Those are gross. The module system is love-it-or-hate-it. The syntax could be most charitably described as "classical" and the compiler itself is held together with reams of duct tape. But it's the first language that's attempting to explore this design space in an industrial setting and encounter all the problems therein (for god's sake, they had to reinvent the notion of closures (and even if you superficially believe they're similar to C++11 closures, the mechanisms required to make C++-style closures memory-safe are novel AFAICT)). Despite all of its flaws (and the upcoming 1.0-stable release will have flaws), it's a remarkably worthwhile language to learn and will influence every language to come that cares to call itself a systems programming language, all because the core ownership system has been so long iterated-upon (and even that will continue to see ergonomic improvements as time goes on).

For memory-sensitive applications where time-amortization hurts (and this turns out to be pretty much every application that anyone wants to run on their local computer), C++ is still king and is still the best choice for the job. Everyone hates C++, and yet every desktop application in widespread use is built with it. I wonder why? Is it really just inertia?

Java, C# - programmers are stuck with a runtime that literally consumes 10x ram as equivalent C++ software. Do you like switching applications on your Android phone and having every other process pushed out of memory? I didn't think so. And while both environments are now offering ahead-of-time compilation, the CLR/JVM runtimes are still much larger than what C++ consumes and you give up the only chance of matching C++'s runtime CPU performance (harvesting runtime profiling to inform the JIT).

Golang - a huge step in the right direction, this will probably end C++ use on servers and hosts eventually. It still can't match C++'s runtime performance, but who cares in a host environment. Still, garbage collection makes it unsuitable for local applications where users notice micro-pauses due to garbage collection. Nothing is worse than going into alpha with 10 P0 bugs complaining about 'micro-pauses' and finding out it's because of something you can't change in the runtime.

D - truly a better C++ than C++. But no one uses it.

Rust - our best hope so far, but the compiler and standard library aren't there yet. You still can't program a web server, for example, without manually handling unsafe objects. Even then its going to be years before there are libraries available that are of similar quality to things like Qt. How do make a GUI application in Rust in 2015?

C - I hope you like (void*) and all of the fun runtime bugs that introduces.

But seriously - "There are better choices in all cases"? Like what?

C++14 (the latest standard) is a far better language than C++ in the '90s, and it really does beat C when it comes to abstraction capabilities, type safety, and standard library functionality. C++11 also defined a standardized memory model which is extremely useful for writing multithreaded code.

Yes, C++ is not perfect -- the C++ standard library lacks a lot of functionality found in the libraries of other languages; there is a lot of complexity in the language that one must master to really "know" C++; the language itself has dark corners and disappointments; and so on. No language is perfect, and every language permits bad code.

I've been working with C++ full-time for the past three years. I didn't know much about the language before then (I was a "C 43var!" guy), but had heard all the horror stories about it. Now, I'm convinced that it's probably the best general purpose programming language available to date. It combines the full power of the machine with very expressive abstraction capabilities. Having seen what can be done with C++, I decided to study harder and try to master it.

I think this last point is ultimately what puts people off, and leads to a lot of FUD about C++ -- it takes hard work to master the language and the tools to work with it. Nobody really wants to do that, not when there are seemingly viable, and easier, alternatives. Instead, people are more willing to invest huge amounts of effort and money to try to scale up those alternatives if it means they can avoid the complexity of a language like C++. That's fine, I guess, we all have to make the appropriate engineering trade-offs, it's just unfortunate that many people fall into extremism about it in order to justify their attempt to simplify the reality of computing (which is actually considerably complex).

This is a bizarre claim. C++ has its problems, but the fact that it allows zero-overhead abstractions over common low-level boilerplate is a seriously non-trivial advantage over C in most areas where C is otherwise a good fit. What compelling advantage does C retain over C++? Faster compiles and being easier to learn are nice and all, but hardly slam-dunks.

However, this could be a chicken and egg problem. People use Java more often so they produce more resources.

All strong in the 90's, sadly the market went somewhere else.

Only Ada seems to survive, but in its own area, high integrity computing.

Its also worth mentioning using a custom allocator + mmap is possible in Go if you really needed it.

Go is also better than Java about using stack allocation for objects.

Modern C++ compilers do auto-vectorization, offer OpenMP, etc. Of course, you can work around this by writing your numerical code in C or C++, let your C/C++ compiler do the work and bind from cgo.

Another shortcoming of Go is that it cannot be used for building non-Go libraries. First of all because the defacto compiler cannot create shared libraries, secondly, because having a garbage collector gives ownership difficulties once you start binding against another language with a garbage collector.

I will not repeat the usual generics stuff, except that lots of optimizations in C++ code rely on generics (e.g. algorithm selection based on the data type or data type properties).

(No, I am not starting Go bashing season ;), I like Go a lot and it can be used to replace C++ in many projects. Just stating the weak points when coming from C++.)

I like Go, but I don't really consider myself an "advocate", and part of that is not overpromising to people. If you've got really heavy-duty computational needs, like in science or graphics, it's a bad choice right now, and I expect it to remain so for the forseeable future because it's not a core concern of the devs, and I'm pretty sure they'd view it as dilution of their goals and value proposition. (Correctly, I might add.)

There's no nginx in development because the built-in net/http library is actually pretty close to it already. Nginx beats it, but only by something like 25-50%, and if you compare the nginx source code to the net/http source code you'll see why nginx is going to likely retain that lead and Go isn't interested in the code quality tradeoff it would take to catch up to nginx. If you ever need an example of C used as "portable assembler", cite the core loop code of nginx.

All the major mobile platforms support C++. Android through the use of the NDK. Windows phone has support C++ since version 8. iOS has supported C++ as long as there has been the app store, either through Objective-C++ or C++ libraries with a C interface.