Show HN: State Trooper – Tiny, no frills state machine for Go • Hacker News Board

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#21

Post by rowls66 » Sat, Jun 17, 2023, 4:53 PM UTC

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.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#22

Post by Solvency » Sat, Jun 17, 2023, 5:50 PM UTC

wahnfrieden wrote: post #15

[flagged]

Rust - A memory safe programming language

wahnfrieden: Why the iron oxide name? Besides the fact that it's a pun. Is the code written with it always bound to be rusty and old?

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#23

Post by wahnfrieden » Sat, Jun 17, 2023, 6:23 PM UTC

Solvency wrote: post #22

wahnfrieden wrote: post #15

[flagged]

Rust - A memory safe programming language wahnfrieden: Why the iron oxide name? Besides the fact that it's a pun. Is the code written with it always bound to be rusty and old?

[flagged]

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#24

Post by jupp0r » Sat, Jun 17, 2023, 6:48 PM UTC

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.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#25

Post by naikrovek » Sat, Jun 17, 2023, 7:15 PM UTC

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

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#26

Post by earthboundkid » Sat, Jun 17, 2023, 7:20 PM UTC

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.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#27

Post by whywouldudothat » Sat, Jun 17, 2023, 7:24 PM UTC

[dead]

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#28

Post by hishamk » Sat, Jun 17, 2023, 7:29 PM UTC

rowls66 wrote: post #21

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.

Thanks for this. You are indeed correct. I've pushed a fix and also added a race test to confirm the fix.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#29

Post by hishamk » Sat, Jun 17, 2023, 7:32 PM UTC

icyfox wrote: post #16

easeout wrote: post #7

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

Midjourney actually does pretty well with this one (needs a bit of cleanup but shockingly useful as a first draft): https://imgur.com/a/GKzx3vX

Ha! Not bad at all.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#30

Post by hishamk » Sat, Jun 17, 2023, 7:44 PM UTC

jupp0r wrote: post #24

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 ben…

Thank you. The focus was on simplicity and handling less complex scenarios. In my current projects the business logic lends itself to sitting outside the FSM/State Trooper. The logic dictates the transitions at arms length to the FSM. The FSM does not carry on any particular business logic, it just enforces the transition rules from one state to any number of possible states - hence why I've included the metadata aspect to embed info about the reason for a transition.

Re the visualization, I think that would be cool. I might give that a shot.