i'd say something that is maybe hard to appreciate until you really get into it is just how much goes into making this ultra scalable with distributed transactions. If you have ~20 mins for it, I wrote this up recently: https://docs.temporal.io/blog/workflow-engine-principles
What I've been working on in recent years is actually not too far off in terms of how to approach making truly simple code, but is far off in the sense that it'll take me (alone) years to make a pragmatic implementation, probably as a language in its own right. Rather than attempt to make a system partition tolerant I started thinking what if network partitions were assumed as the default? To answer that question you have to do things like measure the information entropy of data, use knot theory, representation theory such as young lattices, symmetric group mapping, character groups, prime number theory, among other goodies, to represent event-states, workflows, etc. Most of all (this is where things get weird) is rather than code programs, the emphasis becomes how to easily declaratively code and build "homotopic" multiplexed protocols instead (while keeping the business logic familiar), that way SDKs and integrations are a thing of the past. All this has of course has to use existing web standards like HTTP, otherwise it won't be adopted. My friend always laughs at me when I try to explain it to him, so I apologize, ha. But that's all the more reason to appreciate technology like temporal because it's something a developer can use today.
sounds good, you get it. if you are interested in working with us... we're hiring haha. or happy to help promote if you want to write up your thoughts
while(true) {
Thread.sleep(1, MONTH);
sendReminderEmail(user);
}
...which would normally require one to manually keep track of state in queues and key-value stores and idempotent updates, but with temporal the developer can just focus on the simple business rules. The runtime of Temporal takes care of compiling that down into proper state-machine logic.