Rationale: Or why am I bothering to rewrite nanomsg?

I came to the same conclusion more or less.

Does Go provide meaningful abstractions for writing and managing state machines? Using gen_fsm or gen_statem in Erlang is a critical tool in writing software in a way which _must_ follow some known protocol correctly. Likewise using Session-Types in Rust to go one better than what I get in Erlang (i.e. compile-time assurances vs. runtime ones).

So I was left thinking that Go may be missing meaningful abstractions or facilities for state machine modelling? Or, perhaps more of nanomsg needs to adhere even further to using state machines to define and operate its internal machinery (e.g. the `inproc` race-i-ness mentioned)?

In either case I was confused as to how the conclusion was that state machines were making everything more confusing and less deterministic. Because the point of them is the opposite of that. However, in languages or tools which have poor support for working with them I'm sure ad-hoc interaction with them can be obfuscating and confusing.

They're not better than raw sockets, they're simply an abstraction layer on top of them.

For example, building a message queuing service using raw sockets that works on Windows, Mac OS, and Linux is quite the undertaking. With ZeroMQ (and I'm assuming nanomsg as well), it's quite simple.

ZeroMQ and nanomsg are like raw socket toolboxes.

I hear the claim pretty often that threads won't scale and that even modern OSes can't handle many threads. It makes me wonder if people are doing something different, since I've found that threads are fine.

Berkeley style TCP sockets let you connect to/listen from and endpoint and transfer bytes.

That's pretty cool, but what if you want to send messages rather than raw bytes. What if you want to do publish/subscribe rather than send/receive to a single endpoint? &c.

ZeroMQ implements simple things like that that are often implemented differently in an ad-hoc manner.

Modern operating systems are very efficient at scheduling threads with negligible workloads compared to threads that are performing under load. I suspect that a lot of test code for toy examples and default workload for thousands of threads you see on an operating system has running at any given time is probably not cpu intensive enough to matter.

Compared to this, a library designed to perform actual work using hundreds of threads on a modern os with let's say 8 cpu cores - simply won't work due to the constant context switching overhead. Consider the library called LMAX disruptor as an example of this behavior where developers need to configure threads to be equal to number of available cpus if they wish to do busy_wait processing for inbound messages on the ring buffer. Chronicle Q actually uses JNI to pin message processing threads to individual CPU cores to make sure operating system scheduling does not end up flushing L1/L2 caches and that message processing for a given queue continues to occur on the same thread/cpu combo.

So it depends on your use-case and application.