I have to agree with the article. The writeups from the founders of ZeroMQ always make it seem like a magic bullet, but a few years back when I got down to implementing a distributed 0mq C++ application, it was a hoary mess and we had to implement basic thread pool functionality to keep track of all of our resources. It turns out that we would have been better off using an off-the-shelf messaging solution that kept track of the resources, even with the 'overhead' that an independent broker like RabbitMQ brings. At least the product would have been finished (AFAIK it was scraped and raw binary socket write/reads were used instead).
So the point about Erlang bringing "Fast process creation/destruction" to the table is especially important: if you want to bootstrap an application which needs low-latency, low-overhead distributed message passing, you are better off using Erlang or something else.
So the point about Erlang bringing "Fast process creation/destruction" to the table is especially important: if you want to bootstrap an application which needs low-latency, low-overhead distributed message passing, you are better off using Erlang or something else.