Durable execution semantics (think Temporal, Restate) on top of my #ruby #eventsourcing runtime. You define an execute main method, and flag methods you want to be durable.

@ismasan

Have you done any long-form writing around this? I want to understand better what you are trying to do.

@dcrossney not yet. These are little experiments to exercise a few big changes to my ES library I'm currently working on. But I took this example from this presentation by Temporal, which should give you an idea https://youtu.be/IMAABWxnbUM?t=471
SF Ruby Meetup, August 26 2025, Github HQ

YouTube

@ismasan

Okay, I finally got a chance to watch this. Interesting stuff.

You also said that event sourcing is built on the simpler pattern of durable message stores. This tracks with something that @sbellware of Eventide told me recently (in an unsuccessful interview 😓): the secret sauce is the pub/sub pattern.

I still think that persistence via event sourcing provides unique benefits. Even this video makes clear that durable *execution* is built on the foundation of event sourcing.

@dcrossney @sbellware yes. I’m not sure what was meant by pub/sub, but that term is usually used to refer to real-time, transient messaging (ie event streaming, where publishing an event notifies whoever’s listening right now). In other words, not durable nor replayable. Perhaps it was meant as durable subscriptions and/or consumer groups, that I know Eventose supports?
@ismasan @dcrossney Pub/Sub is orthogonal to issues of the message transport. There's nothing about Pub/Sub that either expects or dictates message durability. There's no "usually" wrt the Pub/Sub pattern. Particular implementations of a pattern may make specific decisions given the use case the implementation addresses, but I'll say with 110% confidence that the Pub/Sub pattern itself - due to the fact that it's a pattern - has nothing to say about any particular implementation.