Comment by giancarlostoro | Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

I think my favorite Actor framework is Microsoft's Orleans, which uses a "Virtual Actor" model. It is mainly implemented in C#, and EA implemented their own version in Java then Kotlin called Orbit, but it feels very straight forward for what it does, it was also used extensively to scale the Halo online servers.

Decent articles on Orleans and Virtual Actor model.

https://learn.microsoft.com/en-us/dotnet/orleans/overview

https://darlean.io/the-virtual-actor-model/

Discussion on Orbit by EA:

https://news.ycombinator.com/item?id=31192795

This basically makes C# behave Erlang esque. You can have a single server running until load kicks off, and even if you destroy a node, spinning it up again is easy. Nodes maintain their own state and can be across systems as needed. You can also do zero-downtime updating like in Erlang. It's really neat. I assume Syndicated Actor Model solves a similar problem, but it looks like they make use of an MQ as needed.

What's funny about Orbit though is the Akka devs wrote some sort of "hit" piece about why their model is fine, and you don't need Virtual Actors.

Orleans is neat because it tackles orthogonal persistence and fault recovery at the same time. Lots of interesting future work remains to be done with persistence, though: wouldn't it be interesting if there were some "third way", somewhere in the middle of spectrum between (1) traditional orthogonal persistence, which serializes the entire nitty-gritty program state (stack, register file, heap, etc etc; totally implementation oriented), and (2) the Orleans or SQL-ORM approach, where the programmer manages records explicitly and, if they're lucky, gets a bit of support to give them a reactive feeling? I'm imagining some kind of domain-specific reflection on machine state, so, a bit like traditional persistence, but filtered through a domain-specific summarization function to yield a domain-relevant data structure describing the state of the actor.

I like the constraints these models impose for some applications, but I don't see them as fundamentally revolutionizing the application development space. You are still ultimately responsible for persisting every last byte of state that these virtual actors embody. Much of this looks like "How to Draw an Owl" [0] to me.

You could tie your own hands in approximately same way in a typical monolithic codebase by spinning out some Actor/Grain base types and enforcing a similar execution model around their implementations.

[0]: https://knowyourmeme.com/memes/how-to-draw-an-owl

Virtual actors are so nice, Dapr[1] uses them as well. You can get hack together something like a virtual actor with Ray too but I'm hoping their actors eventually evolve into something like virtual actors eventually.

[1] https://docs.dapr.io/developing-applications/building-blocks...

Whats funny to me is Dapr is also by Microsoft, but at least you can use it with other languages too.

Reply on news.ycombinator.com