It calls struct methods according to conventions and currently active states (eg BarEnter, FooFoo, FooBar, BarState).
State as in status / switch / flag, eg "process RUNNING" or "car BROKEN".
Each state has a counter of activations & de-activations, and all state counters create "machine time".
The same event happening many times will cause only 1 state activation until the state becomes inactive.
Event subscription will tigger as many times as the event, while waiting followed by a new waiting can miss some "state instances" (those can be infered from the state's clock).
How does asyncmachine compare to Temporal?
Temporal is an all-in-one solution with data persistence, which is its limitation. Asyncmachine doesn't hold any data by itself and has progressive layers, making it usable in a wide variety of use cases (e.g. asyncmachine could do workflows for a desktop app).
How does asyncmachine compare to Ergo?
Ergo is a great framework, but it leans on old ideas and has web-based tooling. It also isn't natively based on state machines. Asyncmachine provides productivity-focused TUI tooling and rich integrations while having every component natively state-based (even the code generator).
Yes, asyncmachine is more of a set of libraries following the same conventions than an actual framework. It can integrate with anything via state-based APIs.
aRPC auto syncs only clock values, which technically is [n]uint64 (n = number of states).
No, just yes/no/later (Executed, Canceled, Queued).
No, but there's an error state (Exception) and Err() getter. Optionally, there are also detailed error states
(e.g. ErrNetwork).
The lack of blocking allows for immediate adjustments to incoming changes and is backed by solid cancellation support.
It was a research project between 2012 and 2019. Video demo.
Usually, the answer is "Make it a state".