

ZeroMQ =/= Erlang - spahl
http://www.rabbitmq.com/blog/2011/06/30/zeromq-erlang/

======
tmarthal
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.

------
jrockway
_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.

~~~
masklinn
> 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.

------
nivertech
How can 0MQ - a library (or even Communication Middleware) can compete with
Erlang/OTP - a Programming Language and Platform ?

They apples and oranges.

Some people use both. There is Erlang binding for 0MQ.

------
koenigdavidmj
Down, and too new for Google cache. Anybody have a mirror?

EDIT: Apparently Google cache works. Linky:
[http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwww.rabbitmq.com%2Fblog%2F2011%2F06%2F30%2Fzeromq-
erlang%2F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-
US:official&client=firefox-a)

~~~
jvoorhis
It's back again.

------
Uchikoma
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 :-)

~~~
piotrSikora
The article is not about ZeroMQ and RabbitMQ, but about ZeroMQ and Erlang.

~~~
Uchikoma
Yes obviously. From the company behind RabbitMQ.

------
sustrik
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.

------
spahl
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!

~~~
plainOldText
which is?

~~~
pjscott
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.

------
Kwpolska
s|=/=|!=|

much better.

