DEdefanor·Oct 11, 2019
That section focuses on ease of use, compared to raw TCP, HTTP, and so on, but I'm rather unsure whether it extends (or is any notable) for arbitrary projects (that is, not counting few for which it is suited particularly well), beyond experimental and basic ones.
I used ZMQ in production 6+ years ago, and there were hard-to-reproduce bugs somewhere. Not sure if I managed to find all their sources before rewriting, but ZMQ was one of the suspects (with a reported bug that would have explained what I have observed, IIRC), certainly less stable than plain POSIX sockets, and making it harder to localize the issue. There is plenty of open issues in the core library still [0]. It's a rather common problem with dependencies and abstractions, not ZMQ-specific, but it adds quite a bit of complexity; if it isn't necessary (or at least very useful)
Read the rest
, I think it's a good idea to avoid. For the past few years I use pipes and UNIX domain sockets for IPC between successors of those programs, and it works well.
Though I keep seeing programmers/software using both TCP and POSIX sockets wrong, making all kinds of wrong assumptions about their operation (and then there are libraries intended to simplify it, but complete with bugs too!); I think that's where HTTP abuse helps by providing a basic API (via relatively polished HTTP libraries) for basic use cases. Probably ZMQ (and other MQs) are indeed useful for that, and for some complex scenarios that one would have to implement from scratch otherwise, but I don't think it's fair to present/recommend as strictly better sockets.
It also talks about distributed P2P, which I find exciting in general, but the example it provides further in the guide only demonstrates automated reconnects and message queuing (which is potentially useful, but not a major challenge).
[0] https://github.com/zeromq/libzmq/issues