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.

It does bring some nice things to the table, but using it has always felt at least a little bit "weird" to me. The docs are a little weird, and there are random caveats sprinkled around the library (e.g. you don't need to synchronize the startup of dependent services like described above, unless you were using certain transports in older versions and so on).

It used to be marketed somewhat towards developing multi-threaded applications, but it was always rather unclear what exactly the advantage of using, for example, the comparatively slow PUSH/PULL socket (ipc:// are pipes) over a MPMC (or as needed) queue ought to be.

It is also marketed towards resilient distributed apps, but, perhaps I was holding it wrong, but it'd always behave much like TCP and stuff like REQ/REP would pretty much always block forever if the peer goes away, while stuff like PUSH/PULL isn't reliable when peers go away, so for a distributed app these can't really be used anyway. So for this use case it always seemed rather too low-level and its guarantees too weak / non-applicable.