3 ms·

From the article: > nanomsg has dozens of state machines, many of which feed into others, such that tracking flow through the state machines is incredibly pain

From the article: > nanomsg has dozens of state machines, many of which feed into others, such that tracking flow through the state machines is incredibly painful. > Worse, these state machines are designed to be run from a single worker thread. Despite the negative tone, the author gives me the impression that nanomsg as a simple, consistent architecture that just needs to be documented better or perhaps refactored. State machines are useful for precisely the reasons the author states: their behavior and performance are easy to reason about and state machines can enable concurrent processing of multiple tasks when when you're limited to a single execution thread. The simplicity of state machines makes them useful for secure code or embedded processes where debug visibility can be poor. Embedded environments like microprocessors also benefit from the single-thread concurrency, but this can also be handy on more capable OSs if you want to cut the latency of fork() or pthread_create(). State machines are a really useful tool; there are worse complaints you could make about a code base.

im_down_w_otp 9y ago
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.
- Matthias247 9y ago
  > Does Go provide meaningful abstractions for writing and managing state machines? Not really more than C. I think in Go the needs are somewhat reduced, since it hasn't the need to use state-machines for actually linear control flow (like making HTTP requests or reading data from a socket without being interrupted). However there are still needs for state-machines, especially when the control-flow isn't linear (more than one event change trigger state-changes). In that case we are mostly back to things like switch/case statements. There are some interesting patterns for running state-machines in separate goroutines, for letting threaded code interact with them. We can e.g. see those in Go's HTTP/2 implementation ( https://github.com/golang/net/blob/master/http2/server.go https://github.com/golang/net/blob/master/http2/server.go ). In this thing the serve() method basically is a giant state-machine that runs on it's own thread. However that's definitely not easy to write, understand and maintain code. A single threaded state-machine is probably much easier to grasp for an average programmer.

im_down_w_otp 9y ago

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.

Matthias247 9y ago
> Does Go provide meaningful abstractions for writing and managing state machines? Not really more than C. I think in Go the needs are somewhat reduced, since it hasn't the need to use state-machines for actually linear control flow (like making HTTP requests or reading data from a socket without being interrupted). However there are still needs for state-machines, especially when the control-flow isn't linear (more than one event change trigger state-changes). In that case we are mostly back to things like switch/case statements. There are some interesting patterns for running state-machines in separate goroutines, for letting threaded code interact with them. We can e.g. see those in Go's HTTP/2 implementation ( https://github.com/golang/net/blob/master/http2/server.go https://github.com/golang/net/blob/master/http2/server.go ). In this thing the serve() method basically is a giant state-machine that runs on it's own thread. However that's definitely not easy to write, understand and maintain code. A single threaded state-machine is probably much easier to grasp for an average programmer.