yes! as long as you don't get unlucky: the runtime might decide to instantiate the other DO in the
yes! as long as you don't get unlucky: the runtime might decide to instantiate the other DO in the same isolate! then you're screwed : )
IE.g. you'd have a primary DO handling storage and 'children', all the children of a DO connect to it's parent through WebSockets and can individually spawn 'children' too.
IAh yes that's a problem.
IYou'd just spawn 10 just to be sure 
ILike a spider laying it's eggs, many will die, but many will survive
Jhaha, they've stacked 21 of my larger objects into the same isolate - which is kind of a big problem - i wish you could specify the "sharing" level or a target mem usage when making the first stub call, that would give them more info on a per-instance basis of when to share or not
Jit's a tough problem, because for some DOs, they could get away with tons of sharing, no way to really tell ahead of time, but they could certainly use the runtime info from prior instantiations - anyway a way for us to specify this either at the class or instance (stub call) level would be awesome
Ji get the sense DOs are not really meant to be large and centralized, it would be difficult to build a centralized pub/sub bus - it seems like they are going more for smaller, user-level-state mostly durable-objects
Jwhich is too bad imo, can think of lots of cool stuff you might be able to build with DOs if they were a bit more predictable in the memory department
HAnyone know if there is a way to delete a Worker with an attached DO namespace if I do not have access to the script anymore?
HThanks, @brett_h!
CThe main difference (IMHO) is that a random worker will be selected to serve any specific request, but you can control which DOs that worker will talk to. That makes the DO a single global point to do stateful computations. Storage (again, IMHO) is secondary to that idea, but it makes DOs even more powerful since you get fast persistence.
CThat description makes sense to me, yes.
JI thought I heard somewhere that workers themselves are called actors internally inside cloudflare, or maybe just DO? naming is hard : )
EI certainly wasn't there when the decision was made to call it Durable Objects, but I vaguely remember there was some pushback from people to use the term actor because DOs don't have the concept on an inbox, which actors frequently have. (But I personally don't think is a defining trait for actions, but oh well)..
EDurable Object is also much smarter from a marketing POV.. which is probably the real reason why it was chosen 
Kyeah, we were going to call them "actors" but we noticed that everyone who was familiar with the actor model ended up getting more confused than enlightened by it, very much like Sergey Bykov's experience (that @toinbis linked above). I don't have any problem with admitting they are in fact virtual actors, as long as people aren't going to then expect to see supervision trees or whatever.
KNobody really loves the name "durable objects", but one thing I do really like about it is that we're using "object" in the object-oriented-programming sense, which I think is the right mental model for people to have when thinking about Durable Objects.
KHah... "Agents" was a name we considered. My argument for it was that "Workers" do whatever random work comes in the door while "Agents" are assigned specific long-term workloads. But other people on the team didn't like it...
IAt this point in my little ChatroomDurableObject I am creating a new WebsocketPair every time a worker connects. This websocket is used to send real-time messages to the workers subscribed. Would it be possible to just create a single WebsocketPair in the constructor of my DurableObject and sent the same 'client' back to all the workers 'subscribing' to it?
HAFAIK, once a name is used to generate an ID, it can't easily be converted back. If you need it again, you could store the name somewhere else.
JSounds like a fantastic intern project
Duhh, this is probably a dumb question... but do Durable Objects have to be serializable? or could they contain something like an RxJS Observable that you can push to between incoming requests?
Dbasically I want to receive "purge" requests from an Amazon SNS and group the tags together and send a request to Cloudflare's API whenever I get up to 30 or every 3 seconds (whichever comes sooner) so that way we are not spamming their API.
Jthey do not need to use at all if that's what you're asking, can do stuff only in memory. The classic websocket chat server for example can be done without storage if necessary. DOs can be just a nice centralized coordination point
Dinteresting, and can you use within a worker?
Derrr
Dwithin the Durable Object
Jyep