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. :-)
@benis @jeff That one was probably from #oggcastplanet, possibly #lobsters, probably not but not entirely impossibly #picolisp. Otherwise I'm on the GS Offtopic, Lounge, Cryptid and Tech/Programming heldscalla matrix channels, #squatconf, #heropunch, #guix, #pump.io and #scuttlebutt. That's more than enough to keep me busy.
I think you are not interested to hear which Swedish-speaking Suckerberg groups I'm on.
@enkiv2 @duck57 @ajroach42 This discussion comes up every so often in the #picolisp crowd. Somebody pops in and says "hey you should do X to get more contributions, to reach a larger audience" (get on git, start a blog, get forums) and Regenaxer will reply that he receives exactly as many contributions and reaches just about the size of an audience he means to. :-D
@natecull I think it's an arbitrary (guided by the language culture's philosophy) choice that many programming languages have had to make over the years. Some languages (Objective C) have their NIL respond to any message with a NIL. Other languages (Scheme, Smalltalk) may respond to some messages, not to others, and may throw exceptions[0].
#PicoLisp has a philosophy that is very pragmatic: "It is easy to produce a segfault in PicoLisp."[1], so I think the liberal choice seems entirely appropriate.
Only a design error will be negatively affected by "infinite NIL", and an infinite recursion because you forgot the base case is usually discovered pretty early in your development.
@drak Very good read. But I think it needs to be said that this assumes that you want your project to improve the world and reach users to do it and you are willing to put in the effort to reach that goal.
Many authors are fine with "I use this, and it just feels like a waste to keep it to myself, so if others want to use it too, that's nice for them.". #picolisp is a bit like this.
I think "avoid success at all cost" could be a factor for some projects as well.
@perloid I have used tcl a bit when playing with expect and sqlite, but I think I learned it when messing with the SunOS package system back in uni.
It's an oldie but goldie and I'd like to do more with it at some point, not the least to look into [incr tcl].
I find it fascinating how Tcl manages to do several things opposite from common wisdom (dynamic scope, references by name only, are the two main ones) yet somehow ends up with equivalent power to more abstract languages like Scheme. #picolisp is rather tcl-like in that aspect and intrigues me too.
@vertigo #picolisp is pretty !forth-like in a sense. Its a very small kernel, it bridges well with machine code and most of it is written in picolisp. But the kernel is in assembler and quite tied to the hardware. pico for x86-64 an x86 even have different features. I guess that makes it both easy and hard to port. Tiny kernel, but you need to rewrite it all each time.