Parallelaware: Is it wise to keep waiting for better concurrency tools, or should developers dive in to solve their problems now with what's available?

Wegrzanowski: Waiting is pointless. There are satisfactory solutions to most of the real-world concurrency problems. For the tiny fraction of problems which require something like Erlang you're on your own anyway -- its niche is so small that it won't create the momentum necessary for turning it into a mainstream language.

P: Have you changed your view that concurrency is best suited to solve latency problems rather than throughput problems?

W: You need an order of magnitude more processes/threads/asynchronous I/O handlers/etc. to deal with high latency than with low latency at the same throughput, so concurrency will naturally occur much more frequently in high-latency situations. Achieving only high throughput usually requires less concurrency and simpler concurrency plumbing. It's a common trick to move latency out of your processing. For example, if waiting for
HTTP request receive and HTTP response send to complete happens in reverse proxy, the main application doesn't need to be aware it's a high latency operation, and can use dumb HTTP queue as its only concurrency tool.

P: Do you find yourself using more concurrency since your 2006 posting (about your concurrent Perl program)? Do you see more concurrency in use among developers of formerly serial programs?

W: Not much. Because of multicore I sometimes have to use a HTTP or JMS queue where before I'd just process a thing serially, but it doesn't affect the code much.

I don't think the much-hyped multicore revolution is real. Vast majority of programs which use sufficient amount of resources to require more than a single CPU are easily decomposable into a bunch of completely independent short-lived single-threaded
actions connected by some sort of a queue (actions being either fork()ed, or more commonly these days processed one at a time by some sort of a worker thread). The queue most commonly being plain HTTP, or maybe something like JMS.

The end result: You can have hundreds or thousands of processes/threads across many many machines, and each of them is programmed exactly as if it was a single-threaded application. So you want to write them in the most convenient language available, which usually happens to be something like Ruby or Python, or maybe something like Java.

The only parts that need to know anything about multithreading is the plumbing, like Apache/ActiveMQ, and it is typically written in C, or maybe Java, as it tends to be really performance-critical.

P: Do you still see Erlang as too removed from the commercial world to be a viable solution? Have other tools or languages gained prominence for you in the interim?

W: There is very little convincing use case for Erlang and concurrency-specific languages. They only makes sense if you need massive number of processes distributed accross massive number of machines (which is somewhat common) which also need massive amount of distributed real-time communication between each other (which almost never happens).

I'm not really following concurrency tools much. As I said, their niche is too small, so I don't expect them to gain momentum ever, unless they happen to be highly concurrency-friendly in addition to some other killer feature.

Do you agree with his views? Why or why not? Write to Parallelaware with your opinions.