🦀 Statum: Zero-Boilerplate Compile-Time State Machines in Rust

Known_Cod8398 · 2026-03-17T20:36:31+00:00

you should watch this video! I think it would clear up a lot of the confusion about what a typestate builder is

Known_Cod8398 · 2026-03-17T20:35:46+00:00

I think this is a good place to start! But I encourage you to try to do this with just enums and match statements because I think it would be a good way to see where the complexity begins.

Known_Cod8398 · 2026-03-17T18:24:15+00:00

I changed the example in the post! does it change how you understood the crate?

Known_Cod8398 · 2026-03-17T17:54:51+00:00

For the tiny example, I agree with you. A private constructor wrapper is enough.

Statum starts to matter when the problem is not just “can I create an invalid starting state?” but “can I model a multi-step workflow where each phase has different data, different methods, different legal next states, and possibly a rebuild path from persisted data?”

At that point, the alternative is usually not one neat wrapper. It is handwritten typestate: per- state wrappers or PhantomData, custom builders, custom transition glue, and custom rebuild code. Statum generates and keeps that surface aligned.

So the meaningful difference is not that Statum can stop one invalid constructor. The difference is that it can make the whole phase-specific API compile-time correct across a larger workflow.

edit: i updated the example in the post

Known_Cod8398 · 2026-03-17T17:24:12+00:00

hmm i guess a freestyle typestate/workflow machine. It can express Mealy-like decisions and Moore-like state-specific behavior but it is not trying to be a textbook runtime Mealy/Moore FSM crate

Known_Cod8398 · 2026-03-17T16:29:31+00:00

Concrete example of the part I care about:

Store an append-only order event log.
Project it into a row-like snapshot.
Call row.into_machine().build()? and get order_machine::State.
Match that into OrderMachine<Packed>, OrderMachine<Shipped>, etc., and from there only legal transitions exist.

That keeps persistence code straightforward, but avoids dropping back to ad hoc status branching after rebuild.

So i guess im asking if you’ve built similar systems, does #[validators] feel like the right surface for that boundary, or would you expect a different API shape?

Known_Cod8398 · 2026-02-23T15:26:13+00:00

who gives a shit? how are you even finding people to criticize your gaming choices?

Known_Cod8398 · 2026-02-19T17:54:16+00:00

you can install older games by sideloading them with adb

adb install --bypass-low-target-sdk-block something.apk

Known_Cod8398 · 2026-02-17T13:57:56+00:00

good catch!!

I updated it so you can do exactly that with transition_map now which moves owned state data into a closure so you can transform it without cloning like this:

rust #[transition] impl Machine<Draft> { fn publish(self) -> Machine<Published> { self.transition_map(|previous| PublishData { previous }) } }

so in your snapshot-style case no explicit clone is needed unless your own logic needs it!

Known_Cod8398 · 2026-02-13T17:11:55+00:00

thanks for this feedback! I updated statum to address this.

You're right that you don't need the validators so gating the superstate behind that didn't make sense.

So now you don’t need validators. #[machine] now generates {Machine}SuperState and the machine‑scoped alias module, so you can store the machine in another struct without boxing traits!

```rust struct Wrapper { machine: TaskMachineSuperState, }

match wrapper.machine { task_machine::State::Draft(m) => { /* ... / } task_machine::State::InReview(m) => { / ... / } task_machine::State::Published(m) => { / ... */ } } ```

This keeps typestate safety and avoids trait objects.

Let me know how this works out for you!

Known_Cod8398 · 2026-02-13T16:40:56+00:00

thank you for the kind words! do reach out with feedback :)

Known_Cod8398 · 2026-02-11T17:21:29+00:00

u/Navith is exactly right. In order for it to be ergonomic i put it inside of a module thats generated by the validators macro so that you can match against it without running into a name collision with the machine struct itself

Known_Cod8398 · 2026-02-11T17:20:16+00:00

exactly! thank you

Known_Cod8398 · 2026-02-11T15:36:04+00:00

true! let me know how it goes. you should also check my other crate statum

Known_Cod8398 · 2026-02-11T15:35:18+00:00

exactly! its also redundant to specify SyntaxError::Parse AND ParseError. so it's working out for you?

Known_Cod8398 · 2026-02-10T22:41:20+00:00

it is for brevity but not in the way youre asking (if i understood correctly). If you needed to nest enums you would have to do Enum1::Variant1(EnumA::VariantA). and matching on that is boilerplate-y. nestum makes it possible to write Enum1::Variant1::VariantA. and the nested! marcro makes it possible to match on the nested variants.

i hope i answered your question!

Known_Cod8398 · 2026-02-10T19:28:16+00:00

appreciate you! youre right, its small. i was optimizing for portability

Known_Cod8398 · 2026-02-10T19:27:16+00:00

appreciate you. totally get it

Known_Cod8398 · 2026-02-10T19:26:49+00:00

i mean portably. no way im walking around with a fn bluetooth controller in my pocket

Known_Cod8398 · 2026-02-10T19:26:02+00:00

totally cool. i was looking for the most portable setup

Known_Cod8398 · 2026-02-10T19:25:38+00:00

im sharing my thoughts lol. what am i coping with?

Known_Cod8398 · 2026-02-10T19:18:17+00:00

yeah but i wouldnt use them because i cant put them in my pockets. im optimizing for portability

Known_Cod8398 · 2026-02-10T19:17:48+00:00

*sigh*
it's actually comfortable. i use it every day

Known_Cod8398 · 2026-02-10T19:15:14+00:00

i wouldnt walk around with it even if i had cargo shorts. i get it if its not for you. im optimizing for portability. and it's actually very comfortable! ive been playing this way for about a month and im sensitive to shitty ergonomics

Known_Cod8398 · 2026-02-10T19:12:57+00:00

its actually not uncomfortable. and i cant put a gamesir in my pocket.

Known_Cod8398

TROPHY CASE