Blog

One of the big strengths of Rust is its use of automatic memory management. When a value gets out of scope, the compiler automatically calls its destructor and frees the memory. During my work on graceful shutdown I have stumbled on a less known interaction between scopes and the _ wildcard pattern that can lead to surprising order of destructors.

Obelisk and DBOS are both open-source durable workflow engines.

Let's see how they compare in terms of ease of use, nondeterminism prevention and performance.

I will go through the Learn DBOS Java tutorial and compare it with Rust version of the same code written for Obelisk. I chose Java because of familiarity, however the library has just been released so the code is still quite young. On the Obelisk side, Rust is the obvious choice as it has the best performance and tooling.

November marks 2 years since I started working on Obelisk, an OSS workflow engine written in Rust.

As a reflection on its capabilities I have decided to make a friendly comparison with WindMill, which produced an interesting benchmark accompanied by a blog post titled Fastest self-hostable open-source workflow engine.

Contrary to vibe coding, usually defined as irresponsible running of LLM generated code with no real code review, leading to security, debugging and maintenance nightmares, "vibe engineering" was defined as "iterating with coding agents to produce production-quality code".

Here is how deterministic workflow engines, and specifically Obelisk, can help with the transition.

Obelisk is an open-source deterministic workflow engine that runs, stores, and replays WASM-based workflows using SQLite.

The headline change in v0.25: every function in workflows and activities is now required to be fallible. Obelisk maps execution-failed errors into the called function's return type. This ensures traps and errors are handled explicitly instead of silently breaking execution.