Unfortunately, the founder of ZeroMQ, Pieter Hintjens passed away (due to cancer) [1]. He was a regular on HN [2].

ZeroMQ still works great and the open source community is still maintaining it on GitHub [3]. I just think people are also looking at other technologies. A lot of interest popped up in things like Apache Kafka and Samsa. I still think ZeroMQ holds a unique place due to its lightweight and simple nature.

[1] https://news.ycombinator.com/item?id=11547212

[2] https://news.ycombinator.com/user?id=PieterH

[3] https://github.com/zeromq

I have been curious how the community would hold up after Pieter's death. This project is a unique case because of how much work went into building community and welcoming contributions. That said, the world is a different place than in zeromq's heyday. Other commenters refer to Martin leaving the project, C++ regret, and a poor fit with node.js. Maybe in the face of all those changes zeromq's mature community is primarily why it lives as a project.

Yes, I am aware that Peter had passed away. I thought that it was implied that the project is not maintained anymore, which is not true.

It has the same momentum, but too much mass and not enough velocity.

In which direction do you want it do move, if you want velocity that is.

I more often find platforms have too much velocity. And if not too little mass, then too little solidity.

Zing!

I recently switched from zeromq to straight libuv sockets with jsonl (\n-separated json) payloads. Because I'm working inside a Node process, combining zmq's threading model with Node's threading model was a pain. Now, there's a single IO thread which is the same as the Javascript engine thread, and I can use uv_work to run CPU-intensive tasks on multiple cores.

Do you not allow \n inside your JSON or encode your JSON as base64? If not you might have problems with disambiguating frame ends from line breaks inside frames.

A common way for framing is to prepend each frame with it's encoded length. That's easier, faster and less error-prone than searching for ASCII delimeters.

If you do the JSON serialization yourself, there's no reason for newlines to be in the JSON. (Newlines within strings are encoded as \n.)

I'm generating the JSON, either with custom C++ marshaling routines or with JSON.stringify which doesn't include newlines unless you give it extra arguments. I believe that any valid JSON can be converted to a single line by changing any '\n' bytes to ' '. Literal '\n' bytes are not allowed inside strings, and outside strings any whitespace is equivalent.

a newline is encoded as the two characters "\n" in json and would not be confused with a literal \n (aka \x0a) character

I think it happened in 2012 when this came out http://250bpm.com/blog:4

Before that, I used to hear people talking about it all the time.

Cool article! I guess that's why Go does its error handling without exceptions.

When the main developer decided that it wasn't good enough and started working on nanomsg (http://nanomsg.org/)

zeromq is still very much in wide use. nanomsg doesn't have nearly as much documentation and community support as zeromq does.

Dunno, I spent close to a week trying to get it to compile with and without encryption on Windows to no avail.

Ended up using a Linux container on Docker to get the thing working.

That is troubling. I always thought of zeromq as having as good Windows support as anything not written exclusively for Windows.

So did I, that's why I selected it. Did my development on OSX and Linux and thought that deploying a static binary on Windows would be a breeze.

It wasn't, turned out to be a Class 4 hurricane :P

Looks like there is a path hardcoded in the build files causing problems. After some reflection on the msvc/README, renaming the project directory to libzmq (was: zeromq-4.2.2 from the release or libzmq-master from github zip download), and launching cmd.exe using the Developer Command Prompt for VS2015 link, libzmq/builds/msvc/build/build.bat successfully builds all configurations.

When was the last time you heard something about it?

When was the last time you heard something about zlib? At a certain point - libraries are basically done. They are widely distributed, everyone knows what they are, there is no reason to talk about them but they are still maintained and heavily used.

Libraries can be done, but that has got nothing to do with momentum. Momentum depends on mindshare, on the willingness of people to use and to keep using it. Most programmers don't choose technology based purely on merits, they choose it based on "I heard X talk about Y and s/he said good things, so I guess I'll use it". We programmers aren't as rational as we think.

Like it or not, popularity and momentum are important merits of a technology. They lead to all sorts of benefits, like healthy maintenance and further development, better documentation, and support when you run into trouble. It is rational to consider these things when choosing technology.

This morning when I used it.

I don't use zmq nearly has much.

I'm using it for a project now. It's a bit weird, but it does work. Cool thing: you can slot a file descriptor into the zmq provided poll ... point is that you can poll on both zmq and sockets in the one loop.

Pro Tip: Use 'cbor' for serialising.

> you can poll on both zmq and sockets in the one loop

Which is magnificent. The ZMQ poller is tons of fun. (Although I think this doesn't work on Windows.)

Thanks for the tip. In which language(s) do you use CBOR? I want to like it, but the various C APIs look a bit cumbersome and lacking docs.

Python 3.