ZeroMQ's variety of socket semantics is great, and it does a good job abstracting away the messy details of TCP. You can build rather complicated systems on top of it much easier and faster than you could using raw sockets. The implementation itself has some rough spots, such as the multi threading. I really like the elegance of nanomsg, but it never really got the same polish that ZeroMQ did. I wouldn't expect the same raw throughput as a hand-tuned TCP based protocol, but it's generally more than fast enough for most use cases.<p>I believe the original developer passed away a few years ago?
I have to say that I have never really had a positive impression of zeromq. I feel like it is particularly unsuccessful and that seems to be for some pretty good reasons.<p>Zeromq is a bag of tools and it's not really clear to me how a novice would put them together safely. This is important for a message system because everyone has to start somewhere and it really shouldn't be "step 1: build your broker with our subroutines". Is that broker really going to be any good?<p>Secondly, for many years zeromq was a kind of monty python style 'judean people's front vs people's front of judea' community. They split from the AMQP standardisation process I agree had clearly gone wildly wrong and then...split and then...split again.<p>Right as far as I know people doing messaging are using a) RabbitMQ if they're deploying it themselves b) AWS of GCP's thing or c) some proprietary thing which has no name recognition among the public (who here has heard of AMPS?) d) Kafka. No one is using zeromq as far as I know! Look forward to anyone sharing their positive experiences using zeromq on big projects eg in banks.
We are using 0mq for monitoring of electric vehicles fleet. Millions of messages every day (hundreds of GB), zero problems with bad internet connection (common in moving vehicles). Every sent message is received regardless of connectivity issues. Just a little implementation annoyances here and there but it is serving us well since 2015.
I looked at zeromq, but it seemed like it had very bad debug-ability and visibility into internal operations. Their FAQ [0] says things like:<p>> How do I determine how many messages are in queue?<p>> This isn't possible. [...] rather than provide incorrect information the library avoids providing any view into this data.<p>> How can I retrieve a list of all connected peers?<p>> This is not supported.<p>Those kinds of decisions are very scary for production environment. We've had to debug network connectivity problems before, and it just possible what all the interfaces Linux kernel provides. I cannot imagine doing it with library which hides stuff from you on purpose.<p>[0] <a href="http://wiki.zeromq.org/area:faq" rel="nofollow">http://wiki.zeromq.org/area:faq</a>
Anyone know how nanomsg (<a href="https://nanomsg.org" rel="nofollow">https://nanomsg.org</a>) or nng (<a href="https://github.com/nanomsg/nng" rel="nofollow">https://github.com/nanomsg/nng</a>) compares?<p>Interesting that nanomsg tries to better zeromq (<a href="https://nanomsg.org/documentation-zeromq.html" rel="nofollow">https://nanomsg.org/documentation-zeromq.html</a>) and then nng tries to better nanomsg (<a href="https://nng.nanomsg.org/RATIONALE.html" rel="nofollow">https://nng.nanomsg.org/RATIONALE.html</a>)<p>edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.
I've implemented bindings for ZeroMQ with Tokio in rust (<a href="https://github.com/cetra3/tmq" rel="nofollow">https://github.com/cetra3/tmq</a>). I found ZeroMQ great for interop with Python/Java if you just want some simple cross-process broadcast/task management.
If curious see also<p>2015 <a href="https://news.ycombinator.com/item?id=9633921" rel="nofollow">https://news.ycombinator.com/item?id=9633921</a><p>2011 <a href="https://news.ycombinator.com/item?id=21226822" rel="nofollow">https://news.ycombinator.com/item?id=21226822</a>
I am sure that the developers behind zmq are(or were) far more intelligent and better programmers than I will ever be, but I have to say that as a user I would never recommend it to anyone for the following reasons:<p>1. A lot of gotchas and surprising behavior. For example this:<p>> To be more explicit: after calling zmq_send the socket may become readable (and vice versa) without triggering a read event on the file descriptor.<p>2. The library will assert internally without actually giving you any clues what did you do wrong as a user.<p>I would rather spend some extra time in development by using pure sockets rather than the stress of debugging problems, arising from the above, later.
I am actually using it in production as an easy mechanism to add non critical rpc calls between services. The only thing I can say about it is that zeromq hasn't given me a reason to look for a replacement. Yet.
Ø is a vowel and a letter used in the Danish, Norwegian, Faroese, and Southern Sami languages. (Wikipedia)<p>It’s not an unused letter that you can snap up as a cool way to write zero. People will read it, some will recognize it and assume it has meaning, because it has. That’s how letters work.<p>There are zeroes with dashes through them, but if you look closely they almost always take care to keep the dash inside the (non-)circle zero to make the difference clearer.<p>I realize most people in the world won’t care about this, but with Northern European eyes, this looks stupid.
Ø - The 28. Letter in the Norwegian alphabet, pronounced as the beginning of the sound ‘uuuuh’ (like when someone is making a sound when thinking). It’s a join between O and E, and was at first written as Ө. The same sound in Swedish is Ö
what I'm wondering is:<p>we have <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a> with sockets in frame 1, and zeromq in frame 3<p>Are there some clear wins of zeromq over sockets/udp/tcp?
In 2015, in one project one "clever" co-worker decided to use "zeromq" in project where is the guarantee of delivery was must. I think that because he wanted to attach this technology as fancy stuff in his cv. Later he left and we had to rewrite message sending and converted to basic http.