Live data from Hacker News

ØMQ – The Guide (2011)

zguide.zeromq.org

51–60 of 117 posts

Re: ØMQ – The Guide (2011)

#51
post #13

what I'm wondering is: we have https://xkcd.com/927/ with sockets in frame 1, and zeromq in frame 3 Are there some clear wins of zeromq over sockets/udp/tcp?

If you have ever written non trivial TCP sockets code you would notice for many purposes that using this saves you lots of very non trivial socket handling intricacies.

For me 0mq works internally, and not for interfacing outside a closed system. I think that might be the source of some confusion

Re: ØMQ – The Guide (2011)

#53
post #48

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.

nice, we're also using it for rpc calls using protobuffs.

Re: ØMQ – The Guide (2011)

#54
post #44

Earlier quoted context omitted.

> we had to rewrite message sending and converted to basic http. What are the delivery guarantees for basic http?

(Yes to the earlier post - had a similar experience with an early metrics system for Twilio in 2012-2013) The 1st issue is that ZMQ implementations generally have an IO thread handling all socket IO. REQ/REP patterns tend to work out just fine, because the client is going to wait for a reply from the server. But things like PUSH/PULL become...harder to follow. You can push things in the client, but how do you know wh…

> But things like PUSH/PULL become...harder to follow.

Surely that implies incorrect use of the socket types vis a vis their design characteristics?

Re: ØMQ – The Guide (2011)

#55

Ø - 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 Ö

> The Ø in ZeroMQ is all about tradeoffs. On the one hand this strange name lowers ZeroMQ’s visibility on Google and Twitter. On the other hand it annoys the heck out of some Danish folk who write us things like “ØMG røtfl”, and “Ø is not a funny looking zero!” and “Rødgrød med fløde!”, which is apparently an insult that means “may your neighbours be the direct descendants of Grendel!” Seems like a fair trade. https:…

Funny - people say "Rødgrød med fløde" because very few non-danes can pronounce it correctly, making it very "funny". It's simply a dish.

I don't know what is more funny ("haha") - people not being able to pronounce it or how stupid hard Danish is to speak.

Re: ØMQ – The Guide (2011)

#56
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.

I believe the original developer passed away a few years ago?

Re: ØMQ – The Guide (2011)

#57
post #21

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: > How do I determine how many messages are in queue? > This isn't possible. [...] rather than provide incorrect information the library avoids providing any view into this data. > How can I retrieve a list of all connected peers? > This is not supported. Those kinds of decision…

To be fair, when you use regular sockets you also don't get much visibility into what your OS is doing, by default. If zeromq provided the information it would definitely be used by app developers misguided to how they are supposed to use it, exactly.

Re: ØMQ – The Guide (2011)

#58
post #53
post #48

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.

nice, we're also using it for rpc calls using protobuffs.

Did exactly the same in a previous job but used flatbuffers for serialization instead.

I wasn't a part of the initial decision making but was pretty happy with how easy it was to work with both zmq and flatbuffers.

Re: ØMQ – The Guide (2011)

#59
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.

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?

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.

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.

Re: ØMQ – The Guide (2011)

#60

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 s…

Pieter Hintjens @hintjens passed away in 2016.
Post reply on HN