A Go library for creating finite state machines and lightweight state machine-based workflows directly in Go code.
Stateless is a Go library for creating finite state machines and lightweight state machine-based workflows. It enables developers to model complex state transitions with entry/exit actions, guard conditions, and hierarchical states directly in Go code. The library is based on UML statechart theory and helps organize processes where entities move between well-defined states.
Go developers building applications with complex state logic, such as workflow engines, device control systems, or business process automation tools.
Developers choose Stateless for its idiomatic Go API, thread safety, and comprehensive feature set including hierarchical states, external storage support, and DOT graph export. It is a direct port of the popular .NET Stateless library, bringing proven state machine patterns to the Go ecosystem.
Go library for creating finite state machines
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Supports substates that inherit behaviors from parents, enabling complex state hierarchies as shown in the phone call example with OnHold under Connected.
Allows state to be stored externally via delegate functions, facilitating seamless use with ORMs or databases, as demonstrated in the NewStateMachineWithExternalStorage method.
Built for safe use in multi-goroutine environments, ensuring reliable state transitions in concurrent applications without additional locking.
Can generate DOT graph representations of state machines, making it easy to create up-to-date diagrams for documentation, as illustrated with the phone call graph.
Uses reflect.TypeOf for trigger parameters, which can introduce runtime panics if types mismatch and may have performance implications.
Configuring external storage requires custom read/write functions and can be cumbersome, especially when handling arguments, as seen in the examples.
Unhandled triggers cause a panic by default, forcing developers to explicitly configure error handling, which could lead to crashes if overlooked.