"Erlang matters today because it demonstrates how these semantics can be elegantly packaged in one language, execution model and virtual machine." I think yes, in a theoretical sense this is absolutely true. The question is why is it not a language in widespread practical use?
1. It kind of is, I think RabbitMQ, CouchDB and Riak are doing ok, for example.
2. Both syntax and semantics are sufficiently different from "industry standard" to be a hurdle for majority of people... I'm being told. I don't understand this; the more different the language is the more interesting it seems to me and the more happy I am to learn it[1], but I heard this argument enough times to accept it as (sad) reality.
[1] And there is still so many of them to learn! Take a look at any one RosettaCode page (http://rosettacode.org/wiki/Y_combinator) if you don't believe me :)
CouchDB is more C++ than Erlang these days, bad example. It hasn't been mostly Erlang for a really long time. Erlang basically only does the clustering behavior, which is something Zookeeper et al. do already.
Riak is the only solid example out of those you listed, and its known for having poor raw performance, excellent availability, easy clustering, and awful usability.
Interesting, where can I learn more about this claim? What are the incompatible facets of a generic queue and Erlang? What is an example of these generic queues (or if it's only an ideal, what are its characteristics)?
If the queue gets badly backed up, you're probably fucked.
Larger, longer-lived work queues are really more of a Hadoop thing, not an in-memory queue thing.
Isn't that true of any queue ?
Where the first answer states that: "RabbitMQ presumes that consumers are mostly online, and any messages "in wait" (persistent or not) are held opaquely (i.e. no cursor). RabbitMQ pre-2.0 (2010) would fall over if your consumers were too slow, but now it's robust for online and batch consumers - but clearly large amounts of persistent messages sitting in the broker was not the main design case for AMQP in general."
(It's contrasted with Kafka, which is "designed for holding and distributing large volumes of messages")
Still, I see no reason why you say that it's Erlang that causes this?
You can implement a queue that works better for batch work in Erlang, it's just that it'd be closer to a data store.
[1] Or at least Joe Armstrong says so in his book, "Programming Erlang".
Can you point to any references?
And scalaris [1]. For me it's killer app for Erlang.
Things are much easier now with line numbers in error messages though.