4 ms·

ZeroMQ has been described by others as a socket-scripting language. You can do Erlang/OTP-style processing over ZeroMQ, it simply doesn't enforce it. In fact,

ZeroMQ has been described by others as a socket-scripting language. You can do Erlang/OTP-style processing over ZeroMQ, it simply doesn't enforce it. In fact, if you wish to do so, you should use (or build) a library around ZeroMQ as an abstraction. The use of that library will resemble the use of Erlang/OTP and will build-in these developer assumptions.

conflagration 14y ago
A really good framework built around ZeroMQ is Storm, which does exactly that: https://github.com/nathanmarz/storm https://github.com/nathanmarz/storm
- ewindisch 14y ago
  For more context, I'm the primary author of the OpenStack ZeroMQ-RPC driver (which does distributed RPC). https://github.com/cloudscaling/nova-mq https://github.com/cloudscaling/nova-mq
loxs 14y ago
As long as you have the "over ZeroMQ" part, it's not Erlang style :). The author tries to explain exactly that. In Erlang the "over X" part is omitted. In Erlang the "over" entity is a processing unit of its own. In abstract terms, in Erlang you don't talk "over" something. You talk "to" things. And even better - you spawn things (processes representing requests) to talk to other things, wait for a response, process that response and even make decisions of their own. And that's exactly the point that the author is making. He is not telling what is possible or what is not. He explains the mindset difference between Erlang programmers and such used to the concepts of "socket", "message queue" or whatever one calls them.
- philwelch 14y ago
  I think the assertion is that you can build the same type of abstraction over ZeroMQ that the Erlang runtime provides, at which point the "over ZeroMQ" part is just an implementation detail.
  - loxs 14y ago
    That is correct. But then, after you implement the system in question, you might not want to call that ZeroMQ any more. In the same way that we don't mention ssh when we talk about our Erlang clusters. And I think, you will lose quite a lot by cutting out all the goodies that ZeroMQ provides. You might not want to do that.

conflagration 14y ago

A really good framework built around ZeroMQ is Storm, which does exactly that: https://github.com/nathanmarz/storm https://github.com/nathanmarz/storm

ewindisch 14y ago
For more context, I'm the primary author of the OpenStack ZeroMQ-RPC driver (which does distributed RPC). https://github.com/cloudscaling/nova-mq https://github.com/cloudscaling/nova-mq

loxs 14y ago

As long as you have the "over ZeroMQ" part, it's not Erlang style :). The author tries to explain exactly that. In Erlang the "over X" part is omitted. In Erlang the "over" entity is a processing unit of its own. In abstract terms, in Erlang you don't talk "over" something. You talk "to" things. And even better - you spawn things (processes representing requests) to talk to other things, wait for a response, process that response and even make decisions of their own. And that's exactly the point that the author is making. He is not telling what is possible or what is not. He explains the mindset difference between Erlang programmers and such used to the concepts of "socket", "message queue" or whatever one calls them.

philwelch 14y ago
I think the assertion is that you can build the same type of abstraction over ZeroMQ that the Erlang runtime provides, at which point the "over ZeroMQ" part is just an implementation detail.
- loxs 14y ago
  That is correct. But then, after you implement the system in question, you might not want to call that ZeroMQ any more. In the same way that we don't mention ssh when we talk about our Erlang clusters. And I think, you will lose quite a lot by cutting out all the goodies that ZeroMQ provides. You might not want to do that.