Some modern languages claim to have better concurrency support than languages like Java or C/C++ (Go, Erlang, etc.). Their features are often touted as making it easier to “get concurrency right,” as though it’s somehow difficult to have similar capabilities in other languages. Sometimes this sounds to me like the closures vs. objects debate.
To demonstrate what I mean, here’s one way to implement a Go-style message channel for inter-thread communication in C++ (using C++11’s thread support):
The age of the single-CPU computer is drawing to a close. Symmetric multiprocessing used to be found only in high-performance servers or scientific computing, but these days it’s in tablets and phones. Hardware designers have been making multi-core parts for years now to keep up with the expected pace of performance improvement. It would be surprising if this trend did anything but continue.
If you’re a programmer and you’re not already writing concurrent software, you should start. 100+ cores could be common ten years from now (or possibly even sooner). At that point, single-threaded software might as well come with a warning label that reads “runs at 1% speed.” This should come as no surprise, as people have been pointing this out for years.
In order to solve problems in my work, I frequently need to extract information from structured text. Often it’s in a report or log file generated by software I don’t control. Other times it’s inside source code in one of a multitude of languages I need to deal with (some of which are domain-specific languages without readily available grammar definitions). Sometimes it’s even to answer complex questions about the structure or behavior of code I need to maintain.
If I’m lucky, I can tackle this with some simple regular expression matching. That kind of text matching has been built into many languages (e.g. Perl, Python, Ruby) for a long time. (C++ has even recently joined the crowd.) Unfortunately, I’m not always so lucky.