Robot, in turn, links to [0], which has a nice section that goes over an example of when all this is useful (which was missing from the Lucy page).

[0]: https://thisrobot.life

I'm on my phone right now, so can't try Robot but I'm wondering what the type safety story looks like. For instance, in the example in "Getting started" the variable `users` is defined irrespective of the state, even though it is only available in the `loaded` state.

And the following part

  Instead of conforming to an XML specification created decades ago, Robot takes the best ideas from both academia and real-world usage of finite state machines. This makes state machines easy to read and understand, as there is only one way to do most common tasks.

...is hinting at some disagreements with XState's approach. Would be nice to have a visualization tool, like the kind XState has, for any FSM library (like robot) though.

The visualization tool goes a long way in helping non-developers understand what logic is actually doing, from a relatively wide perspective. It’s valuable for sure

Where do you see the disagreement with XState's approach?

XState famously always conformed to the SCXML spec[0]. It isn't mentioned anymore in the current version anywhere(?), but you can still see it in the v4 docs[1].

[0]: https://www.w3.org/TR/scxml/

[1]: https://stately.ai/docs/xstate-v4/xstate/advanced/scxml

Thanks!

robot seems interesting, but I wonder why they didn't stick with the elegance of the Lucy language.

Writing a language, even a DSL is a lot of work. It's not enough to just make a good language, there's also a whole world of tooling support that people expect nowadays.

Also ultimately it was hard to sell the idea of living in a different file format from the rest of your code. This is always a tough sell for DSLs. Even languages as good as CSS and SQL struggle with this for a lot of devs.

A JavaScript-only implementation of robot suffers a similar fate as a DSL without proper tooling, as states and actions are just some custom strings that need to be repeated, no? An implmenetation with good types would provide useful autocompletion, and I can see there was a similar conclusion and types have been implemented with generics. Haven't used it yet to confirm the behavior (at a first glance it seems like a few more strings would need to be inferred), but it would be helpful to mention this somewhere for us TypeScript folks.