Distributed programming is a means to an end, not a goal. If you had a computer with infinite cpu and ram and it could never crash and be geographically close to every customer, you would just use that and build your system on it as a dreaded “monolith”. Much simpler to grok such systems. Much easier to debug and monitor.

That’s what temporal enables.

Please correct me if i'm way off base, but at the mental model level, it seems like the key difference between this and Zenaton is:

* Support for multiple languages (Zenaton used to, but doubled-down on Node)

* It runs on your own infrastructure (with Zenaton the code runs on your own machines, but the scheduler runs in their systems)

* A deeper focus on resilience (hard to quantify whether Zenaton has this, but it's definitely not emphasised as heavily)

Hi Andrew, I'm Zenaton's cofounder and you are right Temporal and Zenaton follow the same "workflow as code" pattern. I've written an article recently about it (https://medium.com/swlh/code-is-the-best-dsl-for-building-wo...) - Note that Zenaton is closed now (not enough commercial traction) and I'm working on a new open-source (well Common clauses) implementation of a workflow-as-code engine - similar to Temporal - but with different technical choices (cf. https://medium.com/@gillesbarbier/building-an-event-driven-o...)