5 ms·

ZeroMQ =/= Erlang

77 points by spahl 15y ago

spahl 15y ago
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 15y ago
  which is?
  - malkia 15y ago
    topics on ycombinator?
  - pjscott 15y ago
    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.
- kbutler 15y ago
  The parent is suggesting that easy communication between processes is "the most powerful and interesting part" of Erlang, but I think not. Erlang facilitates reliable, highly concurrent systems using interprocess communication, zeromq just enables the interprocess communication part.
- piotrSikora 15y ago
  You never used Erlang/OTP, did you? ;) 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_*, ...).
koenigdavidmj 15y ago
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%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 http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...
- jvoorhis 15y ago
  It's back again.
tmarthal 15y ago
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 15y ago
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 15y ago
  > 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.
Uchikoma 15y ago
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 15y ago
  The article is not about ZeroMQ and RabbitMQ, but about ZeroMQ and Erlang.
  - Uchikoma 15y ago
    Yes obviously. From the company behind RabbitMQ.
nivertech 15y ago
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.
sustrik 15y ago
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.
Kwpolska 15y ago
s|=/=|!=| much better.

77 points by spahl 15y ago

spahl 15y ago

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 15y ago
which is?
- malkia 15y ago
  topics on ycombinator?
- pjscott 15y ago
  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.
kbutler 15y ago
The parent is suggesting that easy communication between processes is "the most powerful and interesting part" of Erlang, but I think not. Erlang facilitates reliable, highly concurrent systems using interprocess communication, zeromq just enables the interprocess communication part.
piotrSikora 15y ago
You never used Erlang/OTP, did you? ;) 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_*, ...).

koenigdavidmj 15y ago

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%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 http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...

jvoorhis 15y ago
It's back again.

tmarthal 15y ago

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 15y ago

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 15y ago
> 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.

Uchikoma 15y ago

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 15y ago
The article is not about ZeroMQ and RabbitMQ, but about ZeroMQ and Erlang.
- Uchikoma 15y ago
  Yes obviously. From the company behind RabbitMQ.

nivertech 15y ago

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.

sustrik 15y ago

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.

Kwpolska 15y ago

s|=/=|!=| much better.