I’m interested in your opinion on ZMQ vs. other things such as nanomsg - we are currently also using ZeroMQ for communications in Julia (with our own wrapper), but one of the people at my company is concerned because the main person behind ZMQ has died, and apparently not much has been happening with ZMQ since.
Thanks for the info - I’ve passed that on to Maarten (who wrote our ZeroMQ wrapper for Julia, asked me about possible better alternatives for Julia, and sent me the link http://nanomsg.org/documentation-zeromq.html).
Maybe this topic should be split - I’m still interested in whether ZeroMQ (given LGPL, C++ API, etc.) is still the best transport protocol for Julia, whether for networked REPL or services to communicate amongst themselves, or whether people feel there are now better alternatives (besides nanomsg, it seems).
I can anecdotally echo the same sentiments as @StefanKarpinski with respect to nanomsg and other ZeroMQ alternatives being, for all intents and purposes, technological dead-ends. There are alternative transports, but they all exist at slightly different layers than ZeroMQ. For example, AMQP, STOMP, ActiveMQ, etc. provide message distribution semantics that can be implemented in ZeroMQ, but all require significantly more supporting infrastructure than ZeroMQ (or have other limitations such as being JVM-only).
In my experience, ZeroMQ has really found a sweet-spot between raw TCP/UDP and application messaging protocols. The ZeroMQ protocol has also been extensively documented and there is a robust RFC process in place for reviewing and accepting changes to it. Speaking of which, before he died, Pieter Hintjens created the “Collective Code Construction Contract” to guide future ZeroMQ development in his absence.
If there’s any appearance of a decrease in activity around ZeroMQ development, I think that reflects more the fact that it is maturing as a protocol and less that it is becoming, in any way, irrelevant…at least, that’s been my experience.