3 ms·

With sincerely the greatest respect and admiration for what you achieved with ZeroMQ, Pieter, I think perhaps one might be a bit more nuanced when one isn't a

With sincerely the greatest respect and admiration for what you achieved with ZeroMQ, Pieter, I think perhaps one might be a bit more nuanced when one isn't a neutral party. Full disclosure - I wrote a D wrapper, but I am not involved in nanomsg development and just a user. 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 https://github.com/nanomsg/nanomsg/commits/master/src

PieterH 10y ago
Thanks for the updates. I've edited my comment. I've always wanted nano to succeed, just disliked the negative attitude to ZeroMQ expressed in its docs, which seemed unnecessary and damaging.
- kaleidic 10y ago
  Yes, well the little guy always wants to unseat the dominant player, and when there is some personal history involved, things get more mixed up (technical, emotional, manner of expression). In your shoes I would be irritated by that too. But a project if it develops eventually transcends the personalities involved, and that seems to be happening now.
  - PieterH 10y ago
    ZeroMQ is hardly dominant. It's a small player in a huge market and there was and is space for many more projects in this area. I'm glad nano seems healthy again, yet it's not enough, and I'll explain why. 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.
kaleidic 10y ago
Note that I replied to a different version of the parent comment. Thanks for updating. 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.
- PieterH 10y ago
  We use the LGPL license with a clause that makes it harmless. The MPLv2 license is not an issue. All complaints from businesses about licensing come straight to me, as they have for years. MPLv2 raises zero complaints. 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.

PieterH 10y ago

Thanks for the updates. I've edited my comment. I've always wanted nano to succeed, just disliked the negative attitude to ZeroMQ expressed in its docs, which seemed unnecessary and damaging.

kaleidic 10y ago
Yes, well the little guy always wants to unseat the dominant player, and when there is some personal history involved, things get more mixed up (technical, emotional, manner of expression). In your shoes I would be irritated by that too. But a project if it develops eventually transcends the personalities involved, and that seems to be happening now.
- PieterH 10y ago
  ZeroMQ is hardly dominant. It's a small player in a huge market and there was and is space for many more projects in this area. I'm glad nano seems healthy again, yet it's not enough, and I'll explain why. 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.

kaleidic 10y ago

Note that I replied to a different version of the parent comment. Thanks for updating. 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.

PieterH 10y ago
We use the LGPL license with a clause that makes it harmless. The MPLv2 license is not an issue. All complaints from businesses about licensing come straight to me, as they have for years. MPLv2 raises zero complaints. 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.