Hey thanks for the kind words, I am happy you liked the article. You are correct, we did not come up with the rule (but Joran did come up with the name) but drew from the rich history of transaction management systems.
A wonderful paper that I highly recommend is A Transaction Model from Jim Gray, that illustrates like no other than transactions are all about coordinating actions and when to externalize their results to a user. The mental model presented in this paper frequently informs my thinking when designing systems
Yes, exceptions often surprise us in practice. The distinction I'm drawing is more about categorical boundaries than anticipated boundaries: exceptions are part of normal control flow, they are catchable and can be handled. Assertion violations are different: if an invariant is violated, no subsequent action should be trusted.
When we built Distributed Async Await, we went a step further: Every time the generator instance awaits, we "kill" the generator instance (you cannot really kill a generator, but you can just let it go out of scope) and create a new one when the awaited computation completes. So in essence, we built resume semantics on top of restart. We were inspired by the paper Crash Only Software https://dslab.epfl.ch/pubs/crashonly.pdf
That's what we do at Resonate: We build Distributed Async Await, basically async await with durability provided by Durable Promises. A Durable Promises is the checkpoint (the memoization device). When the generator restarts, the generator skips what has already been done.
We don't have workflow and steps tho, like async await, just functions all the way down.
At Resonate, we are using generators (both for the typescript sdk and the python sdk) to implement Distributed Async Await, Resonate's Durable Execution Framework. Because generators transfer control back to the caller, you can essentially build your own event loop and weave distributed coordination (RPCs and callbacks) and distributed recovery (restarts) right into the execution with fairly little lines of code.
A wonderful paper that I highly recommend is A Transaction Model from Jim Gray, that illustrates like no other than transactions are all about coordinating actions and when to externalize their results to a user. The mental model presented in this paper frequently informs my thinking when designing systems
https://jimgray.azurewebsites.net/papers/a%20transaction%20m...