dtornow

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

https://jimgray.azurewebsites.net/papers/a%20transaction%20m...

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.

Disclaimer: I'm the CEO of resonate

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.

Disclaimer: I'm the CEO of Resonate

My favorite mental framework to reason about consistency in distributed systems, Invariant Confluence, was formulated by Peter Bailis at al in Coordination Avoidance in Database Systems (overview and link to paper http://www.bailis.org/blog/when-does-consistency-require-coo...)

Invariant confluence, determines whether an application requires coordination for correct execution.

You can tailor the invariants to your requirements making invariant confluence a much better tool than CAP

The blog post explores the magic of abstractions using the example of database transactions.

Blog post presenting a blueprint for a principled failure handling strategy that aims for correctness and completeness while maximizing the chance of success even in the presence of failure.

Not paywalled

I was part of that debate, I remember a rather interesting point of discussion: Is the main operation "apply" or "dedup"

Apply seems to be the common notion of event sourcing: There is a function apply that takes a state an event and yields a new state. Then, starting in an init state and iteratively applying the entire event history, boom, latest state restored.

Dedup has a lot of charm though: Run and rerun your code, if that step of your code is executed for the first time (no corresponding event in the event history) execute the step and store its result as an event in the history, however, if that step of your code is executed for the second, third time (there is a corresponding event in the event history) do not execute the step and return its result from the event in the history. The Haskell Workflow Package (https://hackage.haskell.org/package/Workflow) is a good example

Temporal follows the second approach, so "proper" Event Sourcing? You be the judge :)

With specifications in First Order Logic (TLA+ syntax)

Author here: I tried to capture networking on a conceptual level, not an implementation level. The idea is to describe the network as a graph of idealized processes and switches. If every message trace that is valid for the model is valid for the actual Kubernetes Network, the model and the network are trace compatible, therefore any true statement about the model is a true statement about the actual network. So far I have gotten some positive feedback, especially from non-network engineers, and some negative feedback, especially from network engineers. Let me know what you think.