Nanomsg guy, Garrett D'Amore, does a really good job rehabilitating the standing of the project and arguing for its utility and raison d'être. The existence of several ground-up implementations of the protocols (C, Rust [1], Go [2]) is interesting, and the nng work (still in C, still wire-compatible, but rewritten at core) and optional WebSocket transport (in addition to TCP, TLS and unix socket) sounds interesting too.
Drew Crawford's (in)famous post-mortem post [3], from two years ago, was written when D'Amore's mangos [2] project, a pure-Go implementation of nanomsg, or rather the nanomsg #scalabilityprotocols, was healthy and going on, whereas nanomsg proper was languishing. He has since stepped up to take over leadership of nanomsg as well.
Apart from a few comparisons with ZeroMQ, governance wasn't discussed much. Nanomsg and nng are described as mainly a one-man show. Too bad, I was hoping for some discussion of people-over-code vs code-over-people and Hintjens's exothermic process post.
The concrete question is asked 39 minutes in, and D'Amore speaks out against consensus and for strong leadership, especially in a small project, the discussion doesn't go very deep beyond that statement. Strong leadership tempered by forking is what he goes for.
On the one hand, it's pretty clear that ZeroMQ has orders of magnitude greater reach and adoption (D'Amore guesses "maybe even two orders of magnitude", but I have the uninformed impression it's more than that). On the other hand I very much support that you decide your definition of "success" and if nanomsg fulfills its task within its design constraints, that's great. We get to use it if we like. On that topic, #picolisp has nanomsg bindings. :-)
that's correct. One of these days I'll get NavierStokes working again...but it may be a while unless I decide to just blow away the server...which might be the best course of action if I want to get this Matrix/Slack integration working this upcoming weekend.