4 ms·

Read the ZeroMQ manual. That's the most important part of ZMQ, as it's the clearest and best guide to your options for partitioning a task and arranging communi

Read the ZeroMQ manual. That's the most important part of ZMQ, as it's the clearest and best guide to your options for partitioning a task and arranging communication between software processes. After that, you can implement your stuff in 0MQ, AMQP, nanomsg, or whatever else. I fully expect nanomsg and 0MQ to compete with each other on Github over the next 5 years or so, and I personally won't take sides. For me, I use the manual to design programs I then write in Rust, a lot of it with no explicit message passing at all. (REQ-REP and PUSH PULL become simple function calls, sometimes mediated through thread spawning, and sometimes not, for example.)

omginternets 10y ago
Hmm, I'm not sure I understand exactly what you're saying. The 0MQ manual is (indeed) excellent, but it seems like a design whitepaper. It essentially describes what are known as the scalability protocols. As you say, it's independent of the implementation, i.e.: the library. My confusion largely stems from a presentation I watched [0] in which it was implied that 0MQ suffered from a few design issues, and had therefore been forked. It seems like the library was rewritten in the meantime, however, so perhaps these points are no longer relevant. I suppose I'm looking for a bit of clarity as to why the fork occurred in the first place.
- ocschwar 10y ago
  That fork was long enough ago that those issues are moot.
- to3m 10y ago
  http://hintjens.com/blog:117#toc4 http://hintjens.com/blog:117#toc4 ``For ZeroMQ, our stated mission was "Fastest. Messaging. Ever." This is a nice, and nearly impossible answer to a problem we could all agree on: namely, the slow, bloated technology available at that time. However, my co-founder Martin and I had conflicting goals. He wanted to build the best software possible, while I wanted to build the largest community possible. As the user base grew, his dramatic changes, which broke existing applications, caused increasing pain. ``In that case, we were able to make everyone happy (Martin went off to build a new library called "Nano").''

omginternets 10y ago

Hmm, I'm not sure I understand exactly what you're saying. The 0MQ manual is (indeed) excellent, but it seems like a design whitepaper. It essentially describes what are known as the scalability protocols. As you say, it's independent of the implementation, i.e.: the library. My confusion largely stems from a presentation I watched [0] in which it was implied that 0MQ suffered from a few design issues, and had therefore been forked. It seems like the library was rewritten in the meantime, however, so perhaps these points are no longer relevant. I suppose I'm looking for a bit of clarity as to why the fork occurred in the first place.

ocschwar 10y ago
That fork was long enough ago that those issues are moot.
to3m 10y ago
http://hintjens.com/blog:117#toc4 http://hintjens.com/blog:117#toc4 ``For ZeroMQ, our stated mission was "Fastest. Messaging. Ever." This is a nice, and nearly impossible answer to a problem we could all agree on: namely, the slow, bloated technology available at that time. However, my co-founder Martin and I had conflicting goals. He wanted to build the best software possible, while I wanted to build the largest community possible. As the user base grew, his dramatic changes, which broke existing applications, caused increasing pain. ``In that case, we were able to make everyone happy (Martin went off to build a new library called "Nano").''