<story><title>State Machines in Rust</title><url>https://blog.yoshuawuyts.com/state-machines/</url></story><parent_chain><item><author>diggan</author><text>For you who enjoying using state machines but wish they did even more and&amp;#x2F;or were embedded in each other (nested state machines!), check out this thing called State Charts!&lt;p&gt;Here is the initial paper from David Harel: STATECHARTS: A VISUAL FORMALISM FOR COMPLEX SYSTEMS (1987) - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.inf.ed.ac.uk&amp;#x2F;teaching&amp;#x2F;courses&amp;#x2F;seoc&amp;#x2F;2005_2006&amp;#x2F;resources&amp;#x2F;statecharts.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.inf.ed.ac.uk&amp;#x2F;teaching&amp;#x2F;courses&amp;#x2F;seoc&amp;#x2F;2005_2006&amp;#x2F;res...&lt;/a&gt;&lt;p&gt;Website with lots of info and resources: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;statecharts.github.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;statecharts.github.io&amp;#x2F;&lt;/a&gt;&lt;p&gt;And finally a very well made JS library by David Khourshid
that gives you lots of power leveraging statecharts: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;davidkpiano&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;davidkpiano&lt;/a&gt;&lt;p&gt;While we&amp;#x27;re at it, here are some links to previous submissions on HN regarding statecharts with lots of useful and interesting information&amp;#x2F;experiences:&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=18483704&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=18483704&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=15835005&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=15835005&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=21867990&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=21867990&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=16606379&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=16606379&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=22093176&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=22093176&lt;/a&gt;&lt;p&gt;My own interest in Statecharts comes from wanting&amp;#x2F;trying to use them for UI development on the web, think there is lots of value to be had and time to be saved by using leveraging it.</text></item></parent_chain><comment><author>RossBencina</author><text>To these links I would also add Miro Samek&amp;#x27;s book &amp;quot;Practical UML Statecharts in C&amp;#x2F;C++,&amp;quot; which covers details of implementing (hierarchical) statecharts. The book includes a chapter that analyses different ways of encoding extended state machines (Miro concludes a function pointer, with one event handler function per state is the best for C&amp;#x2F;C++. I don&amp;#x27;t think this is the encoding that the linked Rust article uses). A simple algorithm for implementing HSMs is described. A large portion of the book is devoted to what you might call &amp;quot;UML Statecharts -- The Good Parts,&amp;quot; the parts of the UML statecharts spec that are easy to implement in a real-time setting, and idioms&amp;#x2F;patterns to achieve similar results as the parts of the spec that are not easy to implement.&lt;p&gt;Some of Miro&amp;#x27;s online writings:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;barrgroup.com&amp;#x2F;embedded-systems&amp;#x2F;how-to&amp;#x2F;state-machines-event-driven-systems&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;barrgroup.com&amp;#x2F;embedded-systems&amp;#x2F;how-to&amp;#x2F;state-machines...&lt;/a&gt;
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;barrgroup.com&amp;#x2F;embedded-systems&amp;#x2F;how-to&amp;#x2F;introduction-hierarchical-state-machines&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;barrgroup.com&amp;#x2F;embedded-systems&amp;#x2F;how-to&amp;#x2F;introduction-h...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.drdobbs.com&amp;#x2F;who-moved-my-state&amp;#x2F;184401643&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.drdobbs.com&amp;#x2F;who-moved-my-state&amp;#x2F;184401643&lt;/a&gt;&lt;p&gt;[Edit: clarity]</text></comment>
<story><title>State Machines in Rust</title><url>https://blog.yoshuawuyts.com/state-machines/</url></story><parent_chain><item><author>diggan</author><text>For you who enjoying using state machines but wish they did even more and&amp;#x2F;or were embedded in each other (nested state machines!), check out this thing called State Charts!&lt;p&gt;Here is the initial paper from David Harel: STATECHARTS: A VISUAL FORMALISM FOR COMPLEX SYSTEMS (1987) - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.inf.ed.ac.uk&amp;#x2F;teaching&amp;#x2F;courses&amp;#x2F;seoc&amp;#x2F;2005_2006&amp;#x2F;resources&amp;#x2F;statecharts.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.inf.ed.ac.uk&amp;#x2F;teaching&amp;#x2F;courses&amp;#x2F;seoc&amp;#x2F;2005_2006&amp;#x2F;res...&lt;/a&gt;&lt;p&gt;Website with lots of info and resources: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;statecharts.github.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;statecharts.github.io&amp;#x2F;&lt;/a&gt;&lt;p&gt;And finally a very well made JS library by David Khourshid
that gives you lots of power leveraging statecharts: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;davidkpiano&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;davidkpiano&lt;/a&gt;&lt;p&gt;While we&amp;#x27;re at it, here are some links to previous submissions on HN regarding statecharts with lots of useful and interesting information&amp;#x2F;experiences:&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=18483704&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=18483704&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=15835005&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=15835005&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=21867990&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=21867990&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=16606379&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=16606379&lt;/a&gt;&lt;p&gt;- &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=22093176&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=22093176&lt;/a&gt;&lt;p&gt;My own interest in Statecharts comes from wanting&amp;#x2F;trying to use them for UI development on the web, think there is lots of value to be had and time to be saved by using leveraging it.</text></item></parent_chain><comment><author>bobbiechen</author><text>Thanks for the links!&lt;p&gt;State machines are pretty cool - I took a digital systems class and found that the concept is straightforward and with a little practice defining states and transitions gets a lot easier. Then implementing a finite state machine (+datapath) with something like SystemVerilog is extremely straightforward.&lt;p&gt;If statechart libraries can help you define what these states are and how data is used, that would be amazing - basically making the whole thing declarative and much less prone to programming error. Google&amp;#x27;s Paxos Made Live paper [1], on the engineering challenges of actually implementing Paxos, actually attests to this value in section 6.1:&lt;p&gt;&lt;i&gt;Fault-tolerant algorithms are notoriously hard to express correctly, even as pseudo-code. [...]&lt;p&gt;We addressed this problem by coding the core algorithm as two explicit state machines. For that purpose,we designed a simple state machine specification language and built a compiler to translate such specifications into C++.&lt;p&gt;[...]&lt;p&gt;We believe that choosing a specification language makes it easier to reason about and modify our state machines than an explicitly coded implementation that is intermingled with the rest of the system. This is illustrated by the following experience.&lt;p&gt;Towards the end of our development of the fault-tolerant log, we had to make a fundamental change in our group membership algorithm. Prior to this change, a replica roughly went through three states. [...but] Intermittent failure turned out to be more common than originally anticipated because normal replicas exhibit intermittent failures from time to time.&lt;p&gt;Thus, we needed to change the algorithm to have two states. Either a replica was in the group or it was out. A replica could switch between these two states often during the lifetime of the system. It took us about one hour to make this change and three days to modify our tests accordingly. Had we intermingled our state machines with the rest of the system, this change would have been more difficult to make.&lt;/i&gt;&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;static.googleusercontent.com&amp;#x2F;media&amp;#x2F;research.google.com&amp;#x2F;en&amp;#x2F;us&amp;#x2F;archive&amp;#x2F;paxos_made_live.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;static.googleusercontent.com&amp;#x2F;media&amp;#x2F;research.google.co...&lt;/a&gt;</text></comment>