Does C++ Suck?
Here’s a blog on how C++ sucks and committee members are an ignorant bunch having little or no clue what they talk about when it comes to threading. I find it interesting to see over and over how people sharply and firmly focus on a single aspect of [insert your favorite issue here, from Iraq war to garbage-collection] and elaborate it to a great extent to prove a point without even bothering to look at the big picture, historical context and value of optimal solution morphed by all the forces acting upon and constraining the issue at hand. Often they have a point in the narrow sense, but they also blatantly disregard any other concern. I guess the world should reboot now, deleting all the code written so far and starting it over in a language so pure and perfect that we’d think we’re in heaven. Before we embark on that journey, someone points us to No Silver Bullet, please. Mixing that kind of “analysis” with arrogance is also often a case. For the intrigued, comp.lang.c++.moderated has discussed the issue, too. I haven’t learned much from that discusion thread.
But wait, here’s the solution to the problem, blogs another expert. It’s called “the Erlang way”. Without pretending to be an expert on the issue, let me take a minute here to share what I have (prompted by the mentioned blogs) recently learned about the Erlang way of concurrency. It’s based on the Actor model. Erlang processes (not to be confused with OS processes) are single threads (not to be confused with OS threads) of execution that share nothing, which makes them safe in a concurrent scenario. They are not operating system processes and are very lightweight, hence cheap to spawn, making Erlang applications readily concurrent in an agile way and very scalable. The Erlang poster-boy, Yaws web server beats Apache hands down in both performance and scalability. However, the important point is that the problem is not in Apache or C. The culprit is actually the operating system and the way it implements concurrency. C (or C++) simply uses the OS API to achieve concurrency. And I’m not sure whether there’s any room for Lin-Win fight in that arena – they seem to be about equally bad, give or take. But hey, worry you not, prudent software professional, that too is about to be resolved by the upcoming world reboot alongside with the operating system rewrite in The Perfect One-and-Only Language. I could actually make a good use of a sabatical decade, and this seems like a perfect opportunity.
Joking aside, who wouldn’t like to see a good solution for concurrency – it’s like an 18-wheeler coming down the road at us. However, there are fundamental reasons preventing true Erlang-like functionality in C++. A significant aspect of Erlang processes is their lightweighted-ness, which comes from the fact that they are spawned with minimal stack size which can later be resized if needed, which, as it turns out, is impossible to achieve without keeping track of the pointers to allocated memory. In plain words – you need garbage collection. For the curious reader, it is explained well in this post. Clearly, nothing comes free, so Erlang pays for this in performance currency – it is slower than C++ when it comes to computing efficiency. So, unless someone can convince the C++ standards committee to sacrifice performance and turn C++ into garbage-collected language running on a VM and have its own (OS independent) threading implementation, the whole discussion is a waste of time. I’ve been thinking long and hard of a “microkernel-like” design for my servlet container – I’d love to load a shared library (or some sort of a lightweight “process”) really quickly and not share my memory with it (i.e. not be vulnerable to anything bad going inside the library). Any way one looks at it – you can’t have it all. There are always trade-offs and that’s the bottom line.
So, back to the original question – does C++ suck? If one looks at some aspects of the language in isolation, a compelling “C++ sucks” case can easily be built. However, when one reads through Design and Evolution of C++, many a reason for language features becomes clear and obvious. Mistakes have been (vector<bool> :-\ anyone?) and likely will be made. However, on average, I’d say that C++ crowd comes across as a pretty sharp bunch. I’ve personally heard Stroustrup say that running multiple threads in shared memory space is simply not a good thing to do. Imagine that, bloggers – even he is aware of it. Unfortunately, we live in an imperfect world and write our imperfect applications in imperfect languages to run them on imperfect machines being controlled by imperfect operating systems. Theo de Raadt puts it well in one of his interviews: “everything we build is turds, we just move them around or shine them or have a different view on which way they should be rolled”.
Concurrency shall be addressed in the upcoming standard. There are some interesting proposals emerging that could make concurrency easier to digest in C++, such as lock-free techniques as presented by A. Alexandrescu and B. Stroustrup. It is important to stay alert, think before you code and expect no miracles. Short of some lunatic pressing the nuke button, the world is not rebooting any time soon. So, looking at it from a broad perspective, C++ does not suck. It is the most succesful general-purpose computer programing language in history. And, for better or worse, warts and all, it still rocks.
