But why ZeroMQ and not nanomsg?
I knew a big part of the reliability problems we were having was related to the distributed state that needed to be kept synchronized. I wanted to move to something simpler that did not rely on any durable, distributed state, while supporting the messaging patters we required. ZeroMQ fit the bill.
While there were other implementations with similar properties, there is no reasonable way to compare them up front given that what makes the real difference at the end of the day is the behavior of the system at 2am one day after a prolonged stress run. As a startup one does not have resources to conduct an up front analysis of that sort. You just take a bet. If it does not pan out, you pivot. This is exactly what we have done with the move from Kafka to ZeroMQ in the first place.
Now that we've been using ZeroMQ for over a year and have been perfectly happy, there is no incentive to look elsewhere.
Did that ever happen? I still like the idea behind nanomsg.
Which is all kind of a shame since it would have been so nice to see a new C engine in the community. We have new engines in C#, Erlang, Java, yet the old core project is still that somewhat clunky C++ engine.
There was some drama when the maintainer quit briefly before rejoining. Since then the gitter channel has been more active than I remember it being before. The mailing list is quiet it is true. Somebody just released a Rust version, and version 1.0.0 of nanomsg was indeed released.
You can see commit history here: https://github.com/nanomsg/nanomsg/commits/master/src
In the end the whole point of ZeroMQ was to build new protocols and APIs for decentralized messaging. My real disappointment with nano was that it made zero effort to build on existing work (mainly, ZMTP) and instead just started again, as if thousands of people hadn't spent years figuring out what a decentralized messaging protocol might look like.
It was worse than that, in fact. Nano launched itself on a wave of negativity. It makes good press, and poor everything else. Such hate for one's own history and knowledge base isn't healthy. If a messaging product isn't aiming at interoperability as a primary goal, it is worthless.
I'm not a fan of the "IETF or bust" approach either. That just doesn't work if you're a decentralized community. We needed and still need lightweight processes for RFC development. We use such a process (Digistan's COSS) in our RFCs. It wasn't random. I built Digistan and COSS over years after seeing AMQP swallowed up and destroyed by a committee. Why isn't nano using a process like COSS?
Without interoperable protocols, all we have is a bunch of software projects. And they die. And then all this is for nothing and the proprietary systems will rule the world and our dreams of making distributed software cheap again will die as well.
And this makes me angry: nano had the chance to push this forwards, and threw it away like old trash. What a stupid, petty waste of opportunity and goodwill.
Personally I started using zeromq, but was a bit disturbed by the experience of the saltstack guys with timeout problems and memory leaks. Probably fixed now, I should think. But more than that, the LGPL and MPL 2.0 licences aren't great for a commercial project that might in future need to be distributed to a different entity. So the license alone is a reason one might welcome greater diversity in available choices.
ZeroMQ "memory leaks and timeouts" wasn't the issue. Do you have a reference for that?
Salt's issues with ZMTP were performance; they wanted to multicast securely, and ZMTP does not support that. I'd complain once again that making their own custom protocol (actually, it seems to be largely just CurveCP) rather than working with us to extend ZMTP was poor form. Also, Salt wanted a pure Python stack.