Hacker News Reader

Comment by loxs | Hacker News Reader

I don't know what exactly do you mean by "dynamic topology" here, but I'll try to explain what the author means, from my Erlang programmer point of view. In ZeroMQ you define a "network topology", however "dynamic" it might be. You define "formal" channels for communication. The computing entities use these channels to talk to each other. In Erlang it's just the opposite. The computing entities are the communication channels. Imagine that you have entity A, communicating to entity C, via channel B. In Erlang you can have (and that's the usual way of programming) that channel B to be a process with computing capabilities of its own. So in fact in Erlang the "network topology" is not merely a means of communication between processes. In Erlang, usually the "network topology" is the program itself.

View on HN

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?

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.

Yes. It's a different paradigm. ZeroMQ and Crossroads I/O deliberately separate the channel from the computation. That allows packages of messaging logic (so called messaging patterns) to be pre-implemented and available out of the box. These deal with complex and hard to get right issues like error handling, pushback and fairness. In Erlang you have to implement these by hand.

Reply on news.ycombinator.com