Live data from Hacker News

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

github.com

51–60 of 63 posts

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

#51
post #20

Earlier quoted context omitted.

Yeah, yet another Algol 60 missing feature. I really don't get how one can suggest the iota const dance with a straight face as an alternative.

what do you think would happen if there was a comment about go on the internet that you somehow didn't see, and to which you weren't able to reply with a sarcastic and sneering dismissal? probably some serious kind of disaster, right?

At crazy as it might seem, I do miss a lot.

Then again, too busy reading papers.

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

#52

Earlier quoted context omitted.

I am working on a state machine formulation/notation that can be executed. The runtime is multithreaded and parallel. The idea is to execute the following state machine: thread(s) = fact(variable) | send(message) | receive(message2); thread(r) = fact(variable) | receive(message) | send(message2); This program waits until thread(s) is true in another thread until thread(r) is true, everything left of the equals symbol…

That is a description of flow-based programming, minus the generalization to "arbitrary packets of data in bounded buffers" - that is, your only data type is true/false and your only buffer size is 1, which lets you get some very clean syntax on it. It's a good invention! FBP adapts the physical concept of unit record machines that operate over punchcard stacks, which predisposes it to thinking in terms of processing…

Thank you syntheweave for an interesting reply.

You're right about the buffers with a truth value in a buffer. I actually use a style of promises or my own count down latch.

I am inspired by Prolog and Drools, a rule engine. I want to "fire" and "retract" facts and the state machine shall work out what to do next.

Here's something that I find especially useful about the formulation: the state machine only moves in one direction, from left to right, but there are multiple transition signals available (facts/atoms) that can be fired to cause the state machine to move forwards.

If you define multiple independent state machines it should be possible to detect "stuck states" where it is impossible for the state machine to continue progressing! This is useful for liveness analysis.

I want the state machine formulation to be useful in designing distributed systems such as Raft.

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

#53
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.

Good eye! Thanks for pointing this out.

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

#55

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

Thank you so much for this head's up. I've just pushed out a new update that covers this and a few other changes.

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

#56
post #38

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

Thanks for the feedback.

The benchmark was for six transitions. I've now updated a few things and added new benchmarks.

I also got rid of timestamps for the map keys - it's back to a regular slice. In retrospect, that was a tad bit off, I agree.

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

#57
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.

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

#58

Earlier quoted context omitted.

This would be hilarious if it was satire

[flagged]

Can you please see https://news.ycombinator.com/item?id=36384562 and stick to the site guidelines? You've unfortunately been breaking them lately.

I'm copying the link here because the other thread is already a bit old and I want to make sure you see it.

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

#60
post #58

Earlier quoted context omitted.

[flagged]

Can you please see https://news.ycombinator.com/item?id=36384562 and stick to the site guidelines? You've unfortunately been breaking them lately. I'm copying the link here because the other thread is already a bit old and I want to make sure you see it.

dang sorry bro but the site guidelines are bad. People regularly endorse straight up atrocities, racism, eugenics, holocaust denial in here and that's all fine if they stay calm and don't say the slurs. I will never not be mad at people defending atrocities and that is the superior transgression. You value civility over human dignity. It's cowardly.

Let me express anger. The people commenting this stuff here expect never to be challenged on it. Expect that they have the right to spew this stuff, carefully, without being told their actions are shameful. It's good for them.

Post reply on HN