Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ØMQ – The Guide (2011)

zguide.zeromq.org

Post reply on HN
Print view View original

31–40 of 117 posts

Re: ØMQ – The Guide (2011)

#31

Post by justinsaccount »

formerly_proven wrote: post #10
fiatjaf wrote: post #3

I have a feeling that ØMQ is a very good thing, but all these years I have never managed to understand what it is and what problem does it solve.

zmq is "a better socket()", but unlike sockets it's pretty hard to figure out what's going on. E.g. most (all?) socket types don't need the other side to be immediately available, it'll buffer a couple thousand or so messages and start blocking if it doesn't appear. From the app's point of view, everything seems fine until the queues are full (which you can't introspect, btw.) when suddenly everything starts blocking…

> REQ/REP would pretty much always block forever if the peer goes away

unless you tell it to do otherwise, that's exactly what it will do. The guide covers this: 4. Reliable Request-Reply Patterns

Re: ØMQ – The Guide (2011)

#32

Post by mhdhn »

parhamn wrote: post #12
fiatjaf wrote: post #3

I have a feeling that ØMQ is a very good thing, but all these years I have never managed to understand what it is and what problem does it solve.

Software is a huge domain. It’s just one of those things you’ll need when you need. Some places you might use it: real-time financial data streams, multi-agent worker task/management, distributed database syncing. It’s basically a networking lib that makes common patterns easier. E.g send this message to everyone, list connected peers, handle these messages this way if the peer can’t take the message, and so on. They…

As OP points out, listing all connected peers is not supported.

Re: ØMQ – The Guide (2011)

#33

Post by francislavoie »

punnerud wrote: post #30

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

In linguistics: https://en.wikipedia.org/wiki/Close-mid_front_rounded_vowel

Re: ØMQ – The Guide (2011)

#34

Post by smitty1110 »

pcglue wrote: post #29

Anyone know how nanomsg ( https://nanomsg.org ) or nng ( https://github.com/nanomsg/nng ) compares? Interesting that nanomsg tries to better zeromq ( https://nanomsg.org/documentation-zeromq.html ) and then nng tries to better nanomsg ( https://nng.nanomsg.org/RATIONALE.html ) edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.

If I remember correctly, they’re written by the original zeromq author. He has a blog post about how he realized that C++ was not ideal for the architecture he was using, and decided to make a clean break.

Edit: Found it. https://250bpm.com/blog:4/

Re: ØMQ – The Guide (2011)

#35

Post by [deleted] »

pcglue wrote: post #29

Anyone know how nanomsg ( https://nanomsg.org ) or nng ( https://github.com/nanomsg/nng ) compares? Interesting that nanomsg tries to better zeromq ( https://nanomsg.org/documentation-zeromq.html ) and then nng tries to better nanomsg ( https://nng.nanomsg.org/RATIONALE.html ) edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.

[deleted]

Re: ØMQ – The Guide (2011)

#36

Post by jhawk28 »

pcglue wrote: post #29

Anyone know how nanomsg ( https://nanomsg.org ) or nng ( https://github.com/nanomsg/nng ) compares? Interesting that nanomsg tries to better zeromq ( https://nanomsg.org/documentation-zeromq.html ) and then nng tries to better nanomsg ( https://nng.nanomsg.org/RATIONALE.html ) edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.

nng is a reimplementation of nanomsg by the guy who made mangos (the go native impl of nanomsg). Nanomsg was written by the original author of zeromq.

Re: ØMQ – The Guide (2011)

#37

Post by m101010 »

random3 wrote: post #16

0mq is great; however, the 0mq Guide is the golden standard for technical documentation and one of the best tech writings there are.

100% agree. I think what stood out to me the most was that it did explain a lot of the decision making. I feel like often other docs don't explain the decisions that did go into their software at all

Re: ØMQ – The Guide (2011)

#38

Post by nurettin »

nurgasemetey wrote: post #26

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.

> we had to rewrite message sending and converted to basic http.

What are the delivery guarantees for basic http?

Re: ØMQ – The Guide (2011)

#39

Post by jacksal »

theamk wrote: 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…

One thing that I didn't like while using it was not being able to get logs out of it. So, you don't know if the issue is from zeromq or app itself. Most of the time, it was app itself but also found a few a bugs in Zeromq which took quite time to find it.

Other than that, great piece of software.

Re: ØMQ – The Guide (2011)

#40

Post by ReactiveJelly »

smitty1110 wrote: post #34
pcglue wrote: post #29

Anyone know how nanomsg ( https://nanomsg.org ) or nng ( https://github.com/nanomsg/nng ) compares? Interesting that nanomsg tries to better zeromq ( https://nanomsg.org/documentation-zeromq.html ) and then nng tries to better nanomsg ( https://nng.nanomsg.org/RATIONALE.html ) edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.

If I remember correctly, they’re written by the original zeromq author. He has a blog post about how he realized that C++ was not ideal for the architecture he was using, and decided to make a clean break. Edit: Found it. https://250bpm.com/blog:4/

His arguments are valid [1] but I still don't understand why that means dropping C++ entirely. Sure, C++ isn't a perfect superset of C, but you could mostly write C-style code in C++, right?

I've seen this sentiment before from C enthusiasts. Maybe it makes sense on the Linux kernel, where you don't want to keep telling contributors not to use the most common C++ features.

But I don't think it makes sense on very small projects, and maybe I just draw the dividing line for where it stops working at a different size of project than he did.

[1] Exceptions suck and constructors suck and C++ would be better if it was just Rust with no borrow-checker.

Post reply on HN