mfateev

Do you realize that Temporal is fully open source under the MIT License, while the competitor is under BSL?

I certainly don't think I'm superior to them in any way and have great respect for the very capable team they are. We know each other personally. I even presented at the Flink conference while at Uber.

My message is that I'd prefer a more technical discussion of the merits of our products rather than simplified marketing attacks.

Disclaimer: I'm a co-founder of Temporal.

Temporal has 3 types of activities:

* local: executed in the same process as the orchestrator code. Many local activities can be executed locally before their results are sent to a backend server in a single RPC call.

* task queue based: executed by a pool of worker processes that poll from the queue. This is the most flexible model as it supports flow control, priorities, fair queueing out of the box.

* eager dispatch: task queue based but executed locally if possible as a performance optimization.

Temporal also supports stand alone activities that are invoked without a workflow and dispatched through a task queue.

Restate only supports local activities (using Temporal terminology).

I wouldn't call it a "more flexible programming model".

Restate made several decisions I consider questionable for the system's availability and stability, like pushing work to handlers instead of dispatching it through a queue. Any design decision has tradeoffs. It would be nice if you mentioned these trade-offs in your posts instead of making claims that sound like pure marketing.

Fun fact: The first-ever Durable Execution POC at AWS Simple Workflow used snapshots. The workflow was implemented as a fully asynchronous Java application, and a snapshot was a dump of the whole object graph using reflection. Performance was abysmal because a snapshot had to be generated after every state transition.

So we switched to replay. The biggest benefit of replay is that it lets you implement Durable Execution in any language as a library without a complex runtime. It also supports code changes while workflows are in flight (Temporal calls this patching). Making snapshots of arbitrary code state backward-compatible with code changes isn't practical.

I personally think that, in the long term, Durable Execution will use a runtime that supports both snapshotting and determinism. That way, snapshots can be taken infrequently, and replay can bring workflow code to the latest state. Similarly to a database recovering from a WAL. WASM is the most promising technology to achieve this.

That sounds like an excellent use for narrow boring company tunnels.

I don't believe in visual programming ever replacing code for general programming. However, many examples exist when visual programs work for narrow domain-specific applications. This works because such applications allow exposing only high-level domain-specific abstractions. This reduces complexity enough to be a good fit for visual representation.

temporal.io just released .NET SDK. The observability and scalability of the platform is really good.

Disclaimer: I'm one of the founders of the project.

Check out temporal.io. It has support for schedules as well.

Check out temporal.io that fully abstract this. Disclaimer, I'm one of the founders.

State machines are useful when the same input/event requires different handling based on the current state. There are not that many applications when this is true. Most of the time only two handlers in each state are needed, success and failure, which are much better modeled through a normal code than an explicit state machine.

At the framework level they might be pretty useful, but they rarely appear at the first version, but as a result of refactoring.

Yes, Temporal workflows are as dynamic as needed.

The other useful pattern is always running workflows that can be used to model lifecycle of various entities. For example you can have an always running workflow per customer which would manage its service subscription and other customer related features.

Look at the temporal.io. It is essentially a BPM system that uses Go (as well as Java/PHP/Typescript) to specify business process. And a queue + DB is never simpler for such scenarios.

Disclaimer: I'm one of the founders of the project.