Both CLIF and pybind11clif aka pybind11k aka pywrapcc seem to be stopped. I thought these were pretty cool projects, I had been following what they did, and even have some of their stuff patched in my local python/c++ ffi code. Did the team just get shifted to something else?

it never gained any real adoption inside google or outside, because it was a lot of work just to get even the most basic bindings. it was really just created because the authors hated swig.

Very cool intro to the subject!

I love nix and use it for my configs and builds at work, but it is definitely hard to get going compared to other tools. I appreciate what you did going through and making some good docs, bookmarked!

I worked on a state machine framework in another language, and have definitely have found less terse to be pretty good. Typing a few extra characters isn't that bad, especially if it makes some awful bit of evented code easier for someone to understand.

Of the things available open source, I think P-lang is pretty cool: https://github.com/p-org/P/blob/master/Tutorial/1_ClientServ...

There are thresholds in both directions, and I find the state_machines examples go way too far in the direction of verbosity to the point where it makes it harder rather than easier to see what is going on.

I'd argue the same for your P-lang example.

The state transitions in your example are trivial to the point where a "framework" is entirely unnecessary, but even then they are hidden inside the implementation details in a way that forced me to read the implementation to realise that they're trivial.

If I have a state machine that is complex enough that I want a "framework" to simplify things, my first requirement will be that it makes clear the state transitions and criteria separate from the implementation of them. Both the state_machines gem and the other Ruby gem mentioned in this thread have examples that in my opinion does a far better job at separating that.