It's just a worker that has state. And because it has state, it also has to have a name, so that you can route to the specific worker that has the state you care about. There may be a sqlite database attached, there may be a container attached. Those are just part of the state.

@KentonVarda Do you have traffic stats on community? Which questions are spiking? This question tripped me up really hard while working to wrap my head around them, and I wonder if others struggle with it: https://community.cloudflare.c...

@tweetsbycolin That's definitely a common request and something we know we want to fix, but turns out to be more complicated than it looks to implement correctly, so it hasn't happened yet.

@KentonVarda @ritakozlov_ I think of them as “containers lite” because you can treat it as a mini-server with its own DB. But I’m an idiot

@markankcorn @ritakozlov_ Ironically one of the problems we're having is that people using our actual containers product -- where each container is attached to a DO for control and scheduling -- sometimes don't like that they have to learn what DOs are.

@KentonVarda hey what happened to the MCP thing though just implemented my first remote MCP API recently so I'm v. curious what you were on about

@theodorvaryag Patience! We're working on it. (I'm always doing 10 things at once...)

@KentonVarda Let the worker be a module. No one wants to deal with a class. Provide examples of a DO written as a module. Simple functions const toto = async () => { ... } and module variables to keep the state.

@DenisTRUFFAUT Multiple Durable Objects may be hosted in the same isolate. Has to be a class so that each one can be instantiated separately. Anyway, many people (e.g. me!) would find it very confusing to store mutable state at the top-level scope.

@KentonVarda that's a very good idea, on the flip side of that idea if the AIs will write the code and architect the app backend soon it maybe doesn't matter what we call things anymore

@KentonVarda Durable Objects might not be self-explanatory so on that front it’s certainly looks worse then stateful workers or some other more descriptive name On the other hand, durable objects entice you to explore, uncover mysterious secrets hidden inside them so imo as a product name

@KentonVarda It wasn't until the last word of this tweet i realized you weren't talking about, like, washing machines and other physical durable goods...

@KentonVarda I find anything I don't fully understand complicated. If I have a WorkerEntrypoint that exports a durable object, an then that worker gets a stub on a DO an calls a method on it, does that happen in the same OS process? Does it run in the same workerd isolate? Can this be

@KentonVarda Big DO fan here, I don’t think it’s the name. The idea of compute, persist, cron, and http server being in one primitive is something that just doesn’t exist, so when you’re looking for the “boundaries” of what this tool does you don’t find them.

@KentonVarda Everything in tech should have an ELI12 docs page with simple diagrams. And that should be the first page of the docs for that thing. Like if this is accurate you should just say this up-front, and *then* get into details.

@KentonVarda Probably because you have to bind them to a worker, instead of just an invisible worker that uses the path to name and route

@KentonVarda We have to thank proprietary object DBs of late 90s-early 00s for that (draconian pricing, Java/C++ exclusivity, closed/unavailable SDKs). I also feel that they ended up with a lot of symbiosis to one language/runtime, by necessity. They are not complicated, it is just that

@KentonVarda At least a worker I basically expect to die and respawn whenever it wants, but it connects to a D1 or a KV that holds all my data. It is just a normal stateless thing that fits in my brain because it's how it has always worker. I like the idea of DOs but I also feel like there

@KentonVarda Workers Databases gets my vote. Make it so they’re addressable by a name as primary API. And build an actual UI for people to see all of them and the data in them, and some kind of automated backup/restore functionality. Basically make the DX match that of a DB. Great product.

@KentonVarda "two hard things: cache invalidation and naming things."

@KentonVarda I think it would be a + in the right direction 👍

@KentonVarda Edge persisted v8 runtime is more descriptive but not as sexy

@KentonVarda i feel like we chatted about this before actors re @BraydenWilmoth @burcs

@KentonVarda yes, big improvement!

@KentonVarda I’d leave the name - renaming it will only cause more confusion imo

@KentonVarda Yes, I think a name change would have an outsized impact

@KentonVarda Sunil’s article here helped frame it for me: https://sunilpai.dev/posts/dur...

@KentonVarda endorse

@KentonVarda yep

@KentonVarda Love that name!

@KentonVarda I think this would help a huge amount.

@KentonVarda i think it sounds complex because most crud monkeys will never need it we were building a game which could have a peak load of a few 100k users we wanted to emit multiplayer events, example player A -attack-> B DO fit the use case perfectly beyond that, i never needed it

@KentonVarda Do people think they are complicated? Most everyone I know avoids building with them, as they are a primitive that doesn't exist outside Cloudflare and thus cause extreme vendor lock-in.