3 ms·

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

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 https://github.com/igrigorik/zeroconf-router

loxs 14y ago
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.
karterk 14y ago
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.

loxs 14y ago

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.

karterk 14y ago

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.