Hi! I work for Restate

A few key differences. Restate has a more flexible programming model. You don't write workflows with activitities, but just durable processes/handlers. Durable steps execute inline and get persisted over an open streaming connection in Restate (low latency, lower overhead per durable step, sharing resources like sandboxes) instead of working with a pull-model where each activity executes remotely on a worker. Restate has a lean deployment model with a single binary that can be deployed multiple times to have a highly-available cluster (potentially spread across multiple regions). It is used for large-scale production clusters, and so lightweight here does not mean less reliable than Temporal.

You can do the same things with Temporal like sleep for months etc. You can learn more here: https://restate.dev/vs/temporal

▲

mfateev an hour ago | parent | next [-]

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.

▲

mshafir an hour ago | parent | prev | next [-]

How does that compare to Inngest? As I understand it it also executes inline and has a streaming connection to the inngest server. We ended up going with them over temporal because it was so much simpler operationally, but restate seems even lighter. I can appreciate how it's hard to tackle the enterprise market, but the temporal solution feels so bloated I really hope the industry can standardize on some simpler patterns

▲

skrtskrt 3 hours ago | parent | prev [-]

How do “stream over an open connection” and things like “sleep for months” play together?

Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.

	▲	stsffap 3 hours ago \| parent \| next [-]
		The way it works is that Restate supports suspending workflows that sleep for months and later (once the sleep finishes) resumes them at exactly this point. Technically, this is the same process as resuming a crashed workflow. While the workflow is actively doing work (like calling other services, accessing state or interacting with external services, for example) the server is connected to the workflow deployment via a low-latency bidirectional streaming connection to receive and acknowledge progress that the workflow makes. That way the workflow can finish as fast as possible. A nice side effect of this model is that you can co-locate your workflow with expensive resources, such as a sandbox, which should be used by all durable actions that the workflow executes. The reason this works is because Restate can inline durable steps (what would be modeled in Temporal as activities, I believe).
	▲	gvdongen 3 hours ago \| parent \| prev \| next [-]
		If a handler starts a sleep/human approval/RPC call, or so, then this timer/promise is persisted in Restate's journal. Restate does the waiting. The handler process itself can suspend (e.g. on a serverless function), and the bidirectional connection is closed. Once the timer fires/approval comes in, Restate re-invokes the service with the journal of previously completed steps, and the service can replay to the exact point in the code where it suspended and continue from there. Restate is like a DB for journals, so you can sleep for as long as needed, also months. So you have fast persistence of events while a handler can make progress, and suspensions while waiting.
	▲	sewen 2 hours ago \| parent \| prev [-]
		I guess the confusion is that it doesn't have to be one single persistent stream. While the durable function does fast work and adds steps, it pushes it through a stream. When a wait point comes, it closes and replays on resumption (typical durable execution style). That gives you the best of both worlds: same long-running workflows with long sleets and suspensions, but also ability to add steps with few ms overhead only.