If you decide to use ZeroMQ be prepared to spend many hours reading the docs and designing the architecture you desire with the building blocks ZMQ provides. Also be prepared to build out wrappers for your developers to use so they have a simplified API to deal with.
Some context (because it's been 3 years already!) :
Cancer diagnosis: https://news.ycombinator.com/item?id=11520888
I never used ZeroMQ much but it taught me a lot of the language around distributed and high-concurrency systems and problems that come up.
I think it took me an hour or three to get some benchmarking programs running when I first encountered it, but that was mostly because I was using the documentation for the wrong major version. So I don't think it's such a big hassle. I definitely continued to learn important things about it for months, though.
It's definitely not a message queuing system like RabbitMQ, though. It's something much simpler and more general.
We use ProtoBuf for the “formatting” of all the data the goes through 0MQ layer. They pair together nicely
This lets us pair together say a processor built in C on one machine to a test GUI built in Matlab on another machine without significant effort.
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), 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).
