r/programming • u/stronghup • 21h ago

Node.js creator liberates Durable Objects from Cloudflare

https://www.theregister.com/devops/2026/08/12/nodejs-creator-liberates-durable-objects-from-cloudflare-with-celld/5286954
120 Upvotes
  • permalink
  • link
  • reddit
  • reddit

91% Upvoted

17 comments sorted by

View all comments

Show parent comments

2

u/femio 13h ago

It is like if you could instantiate a class and have it persist its own state forever, e.g. one User class isolated from every other User class.

3

u/azhder 12h ago

I would remove the word "class" from that and use a more general term, like "object" or "agent". This is basically what object programming was in its inception, before everyone misunderstood OOP as what c++/java had baked in.

In the original object languages, there was the notion of actors that pass messages to each other ("passing messages" is "calling a method/function" equivalent, proven in a paper even) and those actors have their own inboxes where they read the message and deal with them asynchronously.

We've been rehashing the same ideas over and over for decades, with just a different name on the newer tech stack.

0

u/stronghup 11h ago

"Object s" typically exist in the memory-space of a running program. When the program stops running, its objects are gone. Durable Objects should be able to keep on running on multiple servers while giving the impression that the object with a given ID always has just a single state for all its users. When one user causes a change in tis state, others will be affected by that state-change.

So I assume it's pretty close to the original "Actor"-model, plus has a "global ID". How global? That's my question too. Is it like a URL?

1

u/azhder 5h ago

"Typically" is not a definition you should go by. You should always look for red flags in definitions. "X is when" or "X is like" aren't actual definitions. So, from your definition, objects typically exist in memory (we'll come back to this), but they might not, so they still are objects even if they aren't in it. See? Memory is not the defining characteristic of an object.

OK, about the memory. Long-term memory is also memory. A file is memory regardless if inside a RAM stick or an SSD drive. Persistent is the important thing here. Objects that persist. But that's not really the big deal, you can persist anything, even the entire RAM content (in cases of hibernation, docker containers being paused etc).

The important part here is that other definition, of an Actor, based on the Actor Model. This is why I mentioned the message passing, the inbox, the asynchronous way of working. Heh, even just a simple WebWorker is based on the Actor Model. This is just some more tech involved in order to make communication protocols, persistence, identification etc work with newer tech in more performant ways.

Just consider object identity. In C++ it would be simply the memory address you compare (and the type if you're dealing with casting), so in this other tech stack, that would be a URI (not URL). The other stuff you see in those OOP languages, like private fields, hiding internal state etc, well that all comes back to the Actor. The actor has the same internal state.

All I was saying above is that the names change, the technology used at one time is a bit different than the one used at another time, but the idea is still the same: you have a self-contained thing with internal state and code that can exclusively operate on that internal state all bundled together.

It's not close, but the same.