This state machine is inherently unsafe for concurrent use, because the CurrentState and Transitions fields aren't completely protected by a mutex. You already have an unexported mutex that you lock when mutating those fields, but then consumers trying to read those exported fields are not able to lock the same mutex to prevent concurrent read/write operations.

You should not export those fields, and instead make them available via methods where the reads are protected by the mutex. You'll probably also need to make a copy of the map since it's a reference type, OR make the accessor take the key name and fetch the value directly from the map and return it. I learned this when I wrote a similar simple state machine in Go ~7 years ago. :)

I'd also make sure to return `T` from the CurrentState accessor method and not `*T`, just to make it easier for consumers to do comparison operations with the returned result.

Reference on Go memory safety: https://go.dev/ref/mem

Nice job. In my own usage of state machine libraries over the years I have found that for complex use cases, it's definitely helpful to have event-based transition dispatching be part of the library. The great benefit of FSMs is that you can express in data a lot of aspects that you would normally express in code. Not knowing what event needs to happen to transition to one state vs another leaves out a lot of the benefits that you get from designing your code around FSMs.

That being said, I appreciate the simplicity and it's a totally fine choice to leave out event based dispatch for less complex use cases!

One thing that has been mentioned here already: it's super helpful to have your library output a diagram file to visualize the FSM. This is a really great way to keep code and documentation in sync always.

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

Looks cool. It’d be nice if you could output the FSM to some kind of diagram markup (plantuml or mermaidjs).

Interesting. I wrote almost the same code for work a couple of weeks ago.

Not sore, but it looks like the Transition function has a race condition. It calls CanTansition() before acquiring the mutex lock. I think this could lead to illegal state transitions.

May I suggest for a logo: A directed graph in the form of a sheriff's star badge

I saw the benchmark which seemed crazy (3us per transition and allocations). So looked quickly at the code.

Recommend putting the tracking of previous states in a separate optional debugging type so you don’t have to pay the cost in general. Oh and using time stamps as a key is kinda weird, but even weirder in Go where maps are non-deterministically enumerable.

Otherwise, seems like a good use of generics, given Golangs particular take on it.

A state machine (specifically a FSM) class is something I end up having to reinvent in every new language I've adopted. Such a useful pattern whose need comes up repeatedly. Especially in games/sims or in anything with a GUI. Since I've been making both for decades I have a lot of homegrown FSM classes sitting around. :-p

Thanks for everyone's feedback. I've pushed out a few changes:

1- Regular slice instead of timestamp-keyed map. That didn't make sense in retrospect. 2- Better benchmarks. 3- Non-exported current state and transitions. Mutexed getters to avoid concurrency issues. 4- Variadic rule parameters. 5- Better example.

Great name!

    func (fsm *FSM[T]) Transition(...) {
      ...
      fsm.Transitions[time.Now()] = Transition[T]{
       FromState: *fsm.CurrentState,
       ToState:   targetState,
       Timestamp: &tn,
       Metadata:  metadata,
      }

Nice work!! I have always appreciated the clarity of FSMs since first learning about them in college. They are a great way to think about a system's state and given X input, clearly define the next state. This makes them very easy to test as well.

you define Transition over T comparable, but there is no guarantee that comparable implements json.Marshaler, so FSM's MarshalJSON and UnmarshalJSON don't really work

I am actually angry at how good the project name is.

Thanks for this. I like the simplicity!

enums with associated values (like in swift) really are the thing i miss the most in go.

[dead]

[flagged]

[flagged]