5 ms·

But why ZeroMQ and not nanomsg?

PieterH 10y ago
See http://hintjens.com/blog:112 http://hintjens.com/blog:112 for my opinion on why nano isn't (wasn't, perhaps, as it seems to be doing better) a good choice.
- raarts 10y ago
  From the blog: "Crazy Idea: Clone nanomsg, move to zeromq organization, relicense as MPL, support ZMTP, only new socket types and expose CZMQ API." Did that ever happen? I still like the idea behind nanomsg.
  - PieterH 10y ago
    It never happened because (IMO, I'm guessing), no-one actually needs nanomsg. I've never really understood the hostility some people had towards e.g. the ZeroMQ protocols, since these RFCs are as plastic and open to contributions as any part of the project. Yet people like to react against things, and this was a large part of nano's reason for existence. In reality, people who need stable working code just take ZeroMQ and that's it. 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.
- kal31dic 10y ago
  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.
janczukt 10y ago
The answer is rather simplistic and does not even scratch the surface of the drama surrounding zeromq/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.

See http://hintjens.com/blog:112 http://hintjens.com/blog:112 for my opinion on why nano isn't (wasn't, perhaps, as it seems to be doing better) a good choice.

raarts 10y ago
From the blog: "Crazy Idea: Clone nanomsg, move to zeromq organization, relicense as MPL, support ZMTP, only new socket types and expose CZMQ API." Did that ever happen? I still like the idea behind nanomsg.
- PieterH 10y ago
  It never happened because (IMO, I'm guessing), no-one actually needs nanomsg. I've never really understood the hostility some people had towards e.g. the ZeroMQ protocols, since these RFCs are as plastic and open to contributions as any part of the project. Yet people like to react against things, and this was a large part of nano's reason for existence. In reality, people who need stable working code just take ZeroMQ and that's it. 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.
kal31dic 10y ago
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.

janczukt 10y ago

The answer is rather simplistic and does not even scratch the surface of the drama surrounding zeromq/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.