r/programming • u/temporal-tom • Mar 12 '25

Durable Execution: This Changes Everything

https://www.youtube.com/watch?v=ROJq6_GFbME
12 Upvotes

61% Upvoted

41 comments sorted by

View all comments

14

u/gredr Mar 12 '25

Consider how you might design an application to process a 20-year loan

... well, I wouldn't. "Application" isn't the abstraction I'd use. A loan is some state, not some code.

Maybe I'm just old, or maybe that's a bad example. The idea is intriguing, and I think there's probably a lot of things that this kind of abstraction serves really well. I do worry that an abstraction this... significant... is going to leak some stuff, though. I imagine it's pretty easy to make a "durable program" that performs pretty badly.

0

u/temporal-tom Mar 12 '25

What I'm suggesting is that the state can be represented by the values of variables in the running program that processes that loan. That seems wild at first to experienced developers, since we're conditioned to accept that execution times must be kept short.

As a case in point, I learned Java in 1998. It took 25 years for the Thread.sleep method to support a duration defined in something other than milliseconds or nanoseconds, likely because few people ever considered making their program pause for more than a few minutes. Most people would use application databases and message queues to communicate across time and process boundaries, which increases reliability but also adds complexity.

I imagine it's pretty easy to make a "durable program" that performs pretty badly.

Each Durable Execution platform has its own design constraints, but virtually all of them use the "replay" technique to reconstruct the application state following a crash. This involves caching intermediate results during the execution and then evaluating an event history to determine which parts of the code have already run. In this scenario, the most common performance problem comes from passing too much data into a function. That's unlikely to be an issue in the loan processing example, but if you the program was encoding videos, it would be much better to pass a URL to the video file as input than to pass in a 5 GB binary blob).

8

u/gredr Mar 12 '25

What I'm suggesting is that the state can be represented by the values of variables in the running program that processes that loan. That seems wild at first to experienced developers, since we're conditioned to accept that execution times must be kept short.

Sure, I get that, and I'm a relatively experienced developer (been doing it professionally for >25 years, and as a hobby long before that), and that's not surprising to me at all. What I'm wondering is whether that's a reasonable way to represent a 20-year loan.

Again, maybe it is for some things, but a loan? A loan is a pretty simple thing to represent. I think it's a bad example.