Hacker News Reader

Comment by StavrosK | Hacker News Reader

I don't know any Erlang, but, from what I understood (please correct me if I'm wrong), you can consider processes (let's say these are greenlets), connected directly to one another, so all you need to do to send a message is specify whom you want the message to go to. If you want to do, for example, fan-out, you have a process sit inbetween the other processes and distribute the messages.

In contrast, with ZeroMQ you have to have/set up channels, because these are sockets. At least, that's what's apparent to me that the author is saying. Is that correct?

View on HN

That's correct. In addition, you use the processes themselves to encapsulate logic. So the communication channel AND the logical parts that works with them are essentially the same.

An erlang process has a global PID, a ZeroMQ socket has an address - same difference. If you want, you can run everything over named pipes, UDP, TCP, or via an in-memory transport with ZMQ and achieve the same semantics. Case in point: there are plenty actor libraries built on top of ZMQ.

You can run ZMQ devices which can act as routers, and you can easily create fan outs, fan ins, pipelines, and more.

For a mildly interesting example of building a "dynamic" typology, check this experiment: https://github.com/igrigorik/zeroconf-router

Well, of course, you are correct. The author said that in the article. As long as a language is Turing complete, you can use it to do everything that is possible with the other Turing complete languages. But he is not discussing what is possible. You say that a 0MQ socket has an address. That is one of the points the author is making. In 0MQ you send a message to a channel. In a sense, you might not care what entity is going to receive that message, what entity is going to do whatever computation is required and what entity is going to answer your request (or in what language is that entity written). This is very different from the way we program in Erlang. In Erlang every computing entity is directly accessible (as network and in-memory channels are transparent to the Erlang programmer). Usually you talk to entities (and spawn entities to talk to other entities when you need asynchronous requests), not "through channels", and that makes a really big difference to the way we build our programs. Of course, you might argue that it's all the same, but to us, Erlang programmers, it's not. It's a whole new way of thinking.

From my experience, using libraries on top of ZMQ is not the same as using Erlang directly. Yes, you get the same semantics but it never quite feels right, and sometimes will end up reinventing the wheel to end up writing the glue code that resembles a half baked version of Erlang/OTP.

Reply on news.ycombinator.com