Finitomata brings Erlang-style supervision trees to Rust FSMs

Aleix had already ported most of Erlang’s supervision tree model to Rust as `joerl` about half a year earlier and tested that work in production before using it as the foundation for Finitomata. Finitomata takes a familiar Erlang idea and makes it feel native to Rust: instead of scattering recovery logic across callbacks, retries, and helper tasks, it lets you model a machine with explicit transitions and a supervisor that knows how to bring it back.

What Finitomata is really translating

Finitomata is a Rust port of the Elixir Finitomata library, but the more important move is the runtime model underneath it. It sits on top of `joerl`, Aleix’s Rust port of most of Erlang’s supervision tree model.

In Erlang/OTP, supervisors manage child processes and restart them when necessary. Restart strategies include `one_for_one`, `one_for_all`, and `rest_for_one`, and child processes start in order and terminate in reverse order. Worker processes are commonly built with OTP behaviors like `gen_server`, `gen_event`, or `gen_statem`. Finitomata is borrowing that operational logic and re-expressing it for Rust machines that need to survive more than a single happy path.

How the Rust side is modeled

Finitomata provides compile-time validated finite state machines, rich lifecycle callbacks, persistence, and actor-based supervision via `joerl`. That combination is what separates it from the usual enum-and-`match` approach many Rust codebases start with. Instead of leaving transitions hidden inside conditionals, the library pushes state changes into a structured machine definition and a typed async flow.

The quick-start example shows the shape of that workflow clearly. You define the FSM graph with a macro in a Mermaid-like DSL, derive state, event, and payload types from it, and then wire the machine into a `FinitomataSupervisor`. From there, the supervisor can start machines, deliver transitions, and expose cached state through APIs such as `start_fsm`, `transition`, and `state`. The example also shows `auto_terminate = true` and a `build_graph()` step: the machine is declared, built, supervised, and queried through one cohesive path.

What supervision means in practice

The useful translation here is not “Rust now has Erlang.” It is that a Rust developer can adopt Erlang-style failure handling around a finite state machine without giving up type safety. If a machine represents a business process, a job runner, or a protocol flow, the supervisor can own the lifecycle while the FSM owns the valid transitions.

That is the practical payoff of the `joerl` foundation. A supervision tree gives you a way to organize related machines so failures are isolated, restart behavior is predictable, and stateful work can be brought back up in a controlled order. Finitomata folds that into the state-machine layer itself, so the recovery path is part of the design rather than an outer retry wrapper bolted on later.

The repository includes a `persistent_fsm.rs` example. The project is intended for machines whose state has to survive process boundaries, not just for ephemeral transitions inside a single task.

Where it sits among Rust state-machine tools

Rust already has a state-machine ecosystem, and that comparison helps define Finitomata’s niche. `rust-automata` is a DSL for building finite state machines with proc macros, while `rust-fsm` centers on a strict `StateMachineImpl` trait and a simpler, more universal framework. Those crates focus on modeling automata cleanly and enforcing machine rules at compile time.

Finitomata goes further on operational scope. Its distinguishing features are supervision, persistence, and lifecycle callbacks, not just state modeling. If `rust-automata` and `rust-fsm` help you define the machine, Finitomata helps you run it, recover it, and keep it alive when something goes wrong.

The library also lands in the middle of an ongoing Rust conversation about how to model state machines idiomatically. Developers have long debated whether enums and `match` arms are enough or whether more structured abstractions are worth the added ceremony. Finitomata targets long-lived workflows, restart-sensitive jobs, and machines that need both persistence and supervision.

Who should care right now

If you are building async services that currently mix state, retries, and recovery logic by hand, Finitomata is worth studying because it packages those concerns into one typed runtime. The project is especially relevant when a machine has a real lifecycle, not just a single request-response cycle. That includes background workers, protocol state, and business processes that need explicit restart behavior.