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.
You can use poll with ZeroMQ to efficiently use many channels in a single process at once; however, you don’t get to block on particular kinds of message, meaning you have to buffer messages you don’t want to deal with yet, or keep complex state around.
Well, actually, you can have as many ZMQ_SUB sockets as you want connected to the same ZMQ_PUB endpoints, and just set each to subscribe to separate topics.
ZeroMQ is not a message queue. It's sockets++.
If you want a web interface where non-programmers can log in and interfere with your message passing, you don't want ZeroMQ. If you are writing something like X11 or a web server, though, it might be exactly what you need.
> If you want a web interface where non-programmers can log in and interfere with your message passing
wha?
That's not what he was talking about at all, he was talking about selective message reception: when an erlang processes fetches messages from its mailbox, it can do so using a pattern and only messages matching this pattern will be retrieved. And if there is no message matching the pattern, it will just block (can be made to go through directly or with a timeout if needed) until one such message lands in the mailbox.
As others posted, ZeroMQ and RabbitMQ are two different things for different use cases. ZeroMQ is a socket product, RabbitMQ is a message queue. It doesn't help that ZeroMQ uses MQ in it's name. Or perhaps it really means zero MQ :-)
One thing to keep in mind is that 'multithreading magic' article was written when 0MQ was viewed to be equivalent to other MQ systems. The idea of using 0MQ for building multi-threaded apps was really surprising and non-obvious for a lot of people back then.
So, the article focuses on 0MQ =/= SomeGenericMQ and doesn't stress the 0MQ =/= Erlang point of view.
ZeroMQ might not bring the complete power of Erlang to other programming languages but what it brings is, at least in my opinion, the most powerful and interesting part!
Message passing is just part of the language and it's definitely not the most interesting one. It becomes really powerful when you combine all the interesting things together (pattern matching, message passing, lightweight processes, supervisors, gen_*, ...).
Message-passing concurrency that works locally or over a network, with some fault-recovery stuff baked in. At least, that's the intersection of Erlang's coolness and ZeroMQ's coolness.
Really, though, to me that's not the greatest part of Erlang. The great part of Erlang is more that the VM supports lightweight threading, so you can create a vast number of threads and program by message passing, and bugs can be met with micro-reboots by supervisors.
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.