Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thinking in Actors – Challenging your software modelling to be simpler

jeremycarterau.substack.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Thinking in Actors – Challenging your software modelling to be simpler

#41

Post by phtrivier »

withinboredom wrote: post #32
phtrivier wrote: post #27

> State can be persisted (e.g., to storage, database or event log) between messages. If an actor crashes, it can recover its state on another node and resume processing. And that's the part I never managed to solve, personally. The state of actors tend to look "a lot like" your domain objects, but you don't want to store it until the very end. Do you have a data-model for each actor to store their own snapshots ? Whe…

> When do you snapshot ? In Durable PHP (an actor system for PHP), it tries to achieve at-most-once processing guarantee (though more often than not, it is exactly-once). 1. commit the current state 2. send outgoing messages 3. ack the original event If we fail before 1, we simply retry If we fail between 1-3, we simply rewind and retry

Then, it assumes that your actors don't have any side effects. (Otherwise, "retrying" is not an option.)

I found that surprisingly hard in most applications - and I think that's is a limitation of the actor model _in practice_, that is often overlook because it's only an implementation detail that does not really exists _in theory_.

Re: Thinking in Actors – Challenging your software modelling to be simpler

#42

Post by withinboredom »

phtrivier wrote: post #41
withinboredom wrote: post #32

Earlier quoted context omitted.

> When do you snapshot ? In Durable PHP (an actor system for PHP), it tries to achieve at-most-once processing guarantee (though more often than not, it is exactly-once). 1. commit the current state 2. send outgoing messages 3. ack the original event If we fail before 1, we simply retry If we fail between 1-3, we simply rewind and retry

Then, it assumes that your actors don't have any side effects. (Otherwise, "retrying" is not an option.) I found that surprisingly hard in most applications - and I think that's is a limitation of the actor model _in practice_, that is often overlook because it's only an implementation detail that does not really exists _in theory_.

Durable PHP has a way to guarantee exactly-once side effects through "activities" (I assume you are talking about the outside world side-effects, not internally). Trying to do the same activity twice will simply result in merging with the previous execution. This isn't integrated with actors -- mostly because I hadn't thought about it before. It wouldn't be hard to do though.

However, in most async systems, you can only guarantee at-most-once or at-least-once; exactly-once is quite hard (and why there is a dedicated way to do it in this framework).

Internally, messaging is set up to guarantee at-least-once and duplicate messages are ignored (as well as dedicated ways to ensure deterministic execution).

Re: Thinking in Actors – Challenging your software modelling to be simpler

#43

Post by debugnik »

karmakaze wrote: post #28
asplake wrote: post #20

Earlier quoted context omitted.

Why F# there?

I was thinking of Mailbox Processor and available Actor libraries. Here's a pretty good rundown I found for some[0]: > Actor Model in .NET > In the .NET world, there are at least a few battle-tested frameworks that allow you to build stateful systems using the actor model. The famous ones are Akka.NET[1], Orleans[2], Proto.Actor[3], and Dapr[4]. All of these systems support distributed mode, as well as a bunch of oth…

These days, for F# I'd use a task builder loop with System.Threading.Channels and TaskCompletionSource, rather than the MailboxProcessor.

Same thing, really; you could recreate the MailboxProcessor API with those in just a few lines.

Re: Thinking in Actors – Challenging your software modelling to be simpler

#44

Post by jeremycarter »

jerf wrote: post #29
karmakaze wrote: post #9

I suspect that a lot of what can be done with actors can be done in Go using the "Don't communicate by sharing memory, share memory by communicating". Basically a consumer of a channel can act like an actor. What we don't get for free is the activation and resiliency. A closer one would be Erlang/Elixir on the BEAM. On the more advanced end would be using F# or Pony. Curious to see what the follow-up parts will post.…

I view actors like I view "object orientation" in general. In fact they're not even all that dissimilar, being respectively "store and manipulate state attached to a single runtime context" (be it "thread" or "green thread" or async context or whatever) and "store and manipulate state attached to a single highly-structured value". (They go together pretty well, actually.) The primary value comes from the idea, and it…

My sentiments exactly - well said. The big mistake is forcing OOP onto everything. It's why I really have an affinity with the virtual actor, it has just enough OOP for me to have classes, methods and internal state - I don't need inheritance, polymorphism, etc - just naive little classifications of things we call objects.

I also don't have to think of my system in a hierarchical supervised manner like earlier actor models. I just need cloud native distributed little objects.

You can see some modern products coming out that are just that:

1. Cloudflare Durable Objects - https://developers.cloudflare.com/durable-objects/

2. Restate Virtual Objects - https://restate.dev/

Re: Thinking in Actors – Challenging your software modelling to be simpler

#46

Post by jerf »

kiitos wrote: post #40
jerf wrote: post #31

Earlier quoted context omitted.

Any time you are communicating between multiple programming language communities, it is important to understand that they will have differing definitions for things, to extend grace to people trying to communicate across those barriers, and to not apply dogmatic definitions of terms that apply to the contexts you happen to be familiar with but are used differently elsewhere. "Crash" is not a universally defined term…

For sure, yes. But terms of art, like "crash", generally have commonly-understood definitions. And the commonly-understood definition of the term of art "crash" is that it means OS process terminating. Not always! Not all the time. But in general, yes, that's what it means, to most people, most of the time.

This conversation we are having right now, and the other arguments in other comments, is itself the evidence that you are not correct, or if you prefer, correct enough.

Re: Thinking in Actors – Challenging your software modelling to be simpler

#47

Post by jerf »

jeremycarter wrote: post #44
jerf wrote: post #29

Earlier quoted context omitted.

I view actors like I view "object orientation" in general. In fact they're not even all that dissimilar, being respectively "store and manipulate state attached to a single runtime context" (be it "thread" or "green thread" or async context or whatever) and "store and manipulate state attached to a single highly-structured value". (They go together pretty well, actually.) The primary value comes from the idea, and it…

My sentiments exactly - well said. The big mistake is forcing OOP onto everything. It's why I really have an affinity with the virtual actor, it has just enough OOP for me to have classes, methods and internal state - I don't need inheritance, polymorphism, etc - just naive little classifications of things we call objects. I also don't have to think of my system in a hierarchical supervised manner like earlier actor…

I like supervision enough that I reimplemented it in Go myself. I have never found a very compelling reason for hierarchical supervision despite using supervision for well over a decade now in one form or another. I support it, because the supervisors themselves are also services pretty trivially. I've gotten a request to implement the other strategies, but when I asked "why", basically, there was no answer, other than "Erlang implemented it".

I find it useful architecturally to be able to have "a thing that is a service", but, if it turns into "two services", I can have that "thing" simply wrap two services internally with its own supervisor and not change its public interface to need to provide multiple services.

Reading Erlang documentation leads people to believe that they're going to create these elaborate hierarchies of actors that crash other actors if they crash and have complicated restart patterns... and I've never found anything useful other than "if this crashes, please restart it".

I'm sure the other use cases exist. It's a big world and there's lots of needs out there. However from what I can tell at least 90% of the actors in the world don't need much more than basic supervision. That is pretty useful, though. It's amazing what that can paper over out in the field sometimes.

Re: Thinking in Actors – Challenging your software modelling to be simpler

#48

Post by typeofhuman »

jonathanpglick wrote: post #37

This is where erlang/elixir really shines! Using actor processes (aka genservers) to model business workflows and logic helps to align the programmer's and stakeholder's shared understanding and language of a feature, which leads to the implementation and expectations about it to be much more "correct". Too many of us jump straight to modeling the domain objects as database tables without formalizing the the data mod…

> bunch of "status" fields into explicit and hierarchical structures

Could you elaborate some more?

Post reply on HN