YHK - yet another hacker news clone

Buying DRAM?

I'm sure there is a place for restate.dev, but it isn't in the same place as Temporal.

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

Sure, Temporal is more mature and battle-tested, but Restate is quite nice and I honestly prefer it in most cases.

EDIT:

I started drafting this reply before seeing someone from the Restate team chimed in.

temporal centralizes all the error handling, retry handling, ... some web pages to manage failed, pending tasks.

it's been good for us, but a real step function in complexity of the app.

In Temporal, you use their SDK to mark which code is either:

- Deterministic without external dependencies on network, disk, clock, etc.

- Non-deterministic (e.g. accesses a filesystem, dependent on clock time, talks over the network)

You can write the code without handling flakiness or retries and the Temporal control plane handles all the progress tracking and retries for you. Progress is tracked at the individual line of code for deterministic code, or for non-deterministic code, tracked at function boundaries defined by the programmer. You buy into more complexity upfront, but it makes the application code way simpler and easier to manage overall.

They do a lot of other cool stuff on top of all this, and their Temporal Worker Controller architecture is particularly well suited to running massive scale processing/AI workloads on Kubernetes (handles a lot of stuff like autoscaling without interrupting work, rainbow version rollout, etc.)

Basically, a multi-step event handling system, where the data could be spread across multiple databases/systems, so there's no way to rollback a transaction atomically across all the databases. Instead, you explicitly codify "compensations" to undo your previous commits so that you eventually end up in a consistent state.

Temporal is the orchestrator/framework/library to implement the above in an easier way.

Functionally, it's a "workflow" runner (ex - you can mostly treat it like a queue, where you've got workers that are picking up work to do).

But it wraps a couple of pretty handy features on top like:

- It preserves most arguments to actions, and it makes system details deterministic for retries (ex you can re-run a workflow at a later time, and temporal will make sure the code sees details like date and time as though it were the original run, and will yell at you if you try to write code that won't be deterministic on retries)

- It supports very long waits easily. (ex - very easy to have a workflow do a couple things, wait a week, then do some more things).

- It has decent profiling and UI tools

- It can "restart" a failed workflow deterministically from the step at which it failed (using details from the original point)

---

Basically - it's a background worker service that's put a lot of time and thought into ways to handle failures better.

It absolutely still has some considerable pain points though, and I find it difficult to use for larger tasks (ex - their message gRPC size limit of 4mb is a b*&^% to work around, since it often breaks a lot of the utility they provide, and the history cap at 50mb is also really painful in certain situations.)

Really - I think it was just the right tool at the right time to make calling LLMs with long waits relatively easy and somewhat foolproof.

You need to reserve some inventory, charge a card, eventually email a customer and steps can go wrong. So you have queues, and retries and ways to back things out, undo changes.

To my understanding, Temporal's idea is to factor that part out, the queues and retries, and offsetting actions, so you write the logic and not the workflow orchestration.