Hacker News Reader

Comment by antimora | Hacker News Reader

Just recently I have found out that nanomsg is the successor of ZeroMQ. Does anyone have an opinion about this new lib? I am curious how mature and stable it's.

View on HN

Nano is excellent in many ways, though it's not a successor, that's just bombast from its author. ZeroMQ is far more than a library. It is a large community and hundreds of projects, e.g. independent ZeroMQ versions in Java, .Net, C++, Erlang, C. Nano is one library and bindings.

Take a look at the git repositories and the email list and you really see the significant differences. These aren't technical. They're why the ZeroMQ community merges pull requests rapidly, and products tend to be stable on master, while Nano has pull requests hanging for months, and isn't stable.

Nano should have been compatible with ZeroMQ, then it would have been a successor and the protocols could have evolved over time to become what Sustrik wanted. Instead it tried to define itself by one-upping ZeroMQ, missing many opportunities. ZeroMQ has so much stuff built on top. Nano? So little.

This is not accidental or random. The ZeroMQ community is welcoming to people, and every effort is welcome, unless it's really disruptive. Nano is just a the wrong side of hostile, arrogant, and insecure and it shows in the arguments on the mailing list (which we just don't get on zeromq-dev).

Edit: by "not stable", I refer to its "0.5 beta" status, not any technical instability. The point being there is no guarantee of forward compatibility.

Small correction: There is a pure Go implementation of nanomsg (https://github.com/gdamore/mangos).

Ah, indeed, thank you. This is encouraging and I'd like to see more of this. We need spaces for experimentation and competition, and the more libraries attack this "NoBroker" space, the better. I do wish Nano would stand on its own merits rather than the cheap "why we're better than ZeroMQ" marketing. Also I'm somewhat disappointed that Sustrik isn't using Nano in his own new projects (like libmill). That's not a great vote of confidence.

> I do wish Nano would stand on its own merits rather than the cheap "why we're better than ZeroMQ" marketing.

IIRC, 0MQ launched with quite a lot of "why we're better than AMQP" marketing.

True, and perhaps Nano was inspired by this. However look carefully and you will see that we never, ever, criticized RabbitMQ. I know the team that built it, they are friends, and we both invested crazy amounts of time in trying to keep AMQP alive. RabbitMQ is an excellent product, built with cool technology. The protocol is not so good. I designed it, I know its weaknesses. It is way too complex, and strangled by a committee that could not innovate and preferred to bully and lie its way to a "1.0" version that broke everything and delivered so little it's barely a messaging protocol, let alone "advanced".

It is fun to compare products. The competition between RabbitMQ and ZeroMQ was deliberate, useful, and good for both projects. However for a breakaway project to claim "we're the successor" is downright silly IMO. Hostile and negative, and sets a terrible tone for a young project. And if you can't achieve that, what then?

I find this rather sad, and looking at Nano's commit history, another of those entirely predictable stories. Why would you want to supercede the ZeroMQ community? It's large and successful and friendly. Why not simply make a better ZMTP engine? Make it smaller, cleaner, compatible, and then over time, improve the protocols... simple and undramatic and guaranteed success.

But no, we need drama and argument and hostility and... no matter how good the code, the outcome is that contributors don't stick, the core developer gets burnt out, and the project dies.

It happened to Crossroads, and Nano appears to be really just the same, in C. The waste in time and effort is sad. We need projects like Nano. We need space for new experiments. We need choice and competition.

I've spoken to some Nano contributors who are replacing Sustrik (who seems to have abandoned the project), and things may improve. One hopes.

There's nothing as comprehensive as the ZMQ guide for documentation, but here[1] is a good place to get started. It seems fairly stable API wise at this point.

I haven't used it much, since there's no way to switch from ZMQ without losing wire-protocol compatibility, and I haven't started any new projects that need IPC recently.

1: http://tim.dysinger.net/posts/2013-09-16-getting-started-wit...

I built our entire monitoring infrastructure on top of nanomsg and nodejs; previously I used zmq. Over the last 3 months, I've had absolutely no issues with a bit over 200 servers communicating with each other.

Pretty cool stuff.

I used nanomsg to have 20+ servers listening to queue from a single master.

I found that over time the memory consumption would rise horridly and I had to stop using it. I've just had another sanity-check of my code and don't spot an obvious leak, but I'm willing to believe it is there:

https://github.com/skx/nanoexec

Otherwise though using nanomsg was a pleasure, and I have it in use elsewhere without problems.

its actually not a successor, but a fork by one of zmq's core devs, Martin Sustrik.

there is a writeup in the docs how nanomsg differ from zmq: http://nanomsg.org/documentation-zeromq.html

Reply on news.ycombinator.com