I went around and asked a bunch of them with a similar idea (see the above comment of mine), and you'd be surprised to hear that they all hated the idea. They mostly just don't want to deal with anything where they fear that the person vibed the submission. Just no desire to engage with at all, because they've got so many bigger problems with the avalance of code coming their way.
Hey! durable writes for celld (single node, wait for bucket) is 90ms. Documented pretty clearly on the landing page.
Celld is pretty cool in that you can configure a small fleet in the same VPS and get super fast durable writes (with a weaker guarantee). We are also going to allow you to tweak the durability guarantees so you can manage that trade off yourself!
> super fast durable writes (with a weaker guarantee)
Nope. you just run it on 2 VMs in same zone and get 1ms (ack on durable disk write).
I'm surprised at your technical language. Either you're ignorant of basics of how other key durable systems works, or you're misrepresenting a unnecessary worse case. Neither inspires confidence in your work.
Cells documentation is good. I'd suggest pointing an agent to them and requesting a deployment setup for low latency. It should suggest 2 Vms in same AZ on a cloud of your choice - LAN setup.
Hey! Yea we are a very different API from them. Closer to Cloudflare for sure.
Our biggest differentiator is the configurable compute. With our helm chart, you just add a decorator and can specify how much RAM, CPU etc... an actor class has.
We are pretty opinionated on how to host these. The helm chart gets you a fully horizontally scalable deployment.
Olivier's comment seems to have been suppressed. Not sure why. reposting
thanks for the question verst. durable actors manages durable state, not durable execution. Azure Durable functions, temporal, aws lamda durable functions are for managing execution.
each actor has its own sqlite DB and runs on one host at a time. Clients call it via RPC or Websocket message, changing state and actor pushes state changes back to every client. product is more similar to cf durable objects or orleans.
i took a look at durable entities, state model is similar but they don't support websocket handling.
This is a great comment! We actually get this a lot.
Since we are so early, we can build this the right way. I agree, I think we need something you can set up to sync to a data lake. I started really simple with exporting at certain times, but I think there is more to do here.
I really want to nail this part of the experience. I agree, it is a big sticking point
Hey! so celld is a direct port of Durable Objects.
We are actually a different API. I come from writing swift for 7 years (I was at apple) and really thought they nailed the actor model so modeled ours similarly.
Also, we make it really easy to configure each actors compute with just a decorator. So if you want to do something beefy like store file directory in an actor you can increase the memory to 4GB and you are good to go!
> I come from writing swift for 7 years (I was at apple) and really thought they nailed the actor model
Which actor models are you comparing to? What do you think of Erlang/Pekko/Pony?
I roughly understand their models but have never looked at Swift's. On the surface it looks like it borrows heavily from each of these (now that I'm looking) which sounds potentially awesome. I suppose I'm curious what you think makes Swift's model 'nailed' relative to alternatives.
It's pure curiosity. I love actor models and enjoy learning about the paradigm in general.
