[kiitos]

    Isolation: Since actors process messages they receive sequentially, there are no concurrency issues within an actor. This simplifies reasoning about state mutation and transitions.
    ...
    Fault Tolerance: 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.

The system model in which each actor instance is single-threaded, processes received requests individually and sequentially, and can "crash" in a way that affects only the in-flight request, is a total anachronism, irrelevant since more than a decade, at any meaningful scale.

[packetlost]

I don't see how this isn't still both possible and entirely relevant to modern systems. An actor is not necessarily a system process/thread. It has more to do with scope/context than any particular execution model. Think more like a request handling context in an async language.

[kiitos]

It's true that an actor is not necessarily a system process. It can be a process, or a thread, or a coroutine, or etc. But "crashing" isn't anywhere near so ambiguous. Crashing doesn't mean the request fails, or the thread gets killed -- crashing means the underlying process terminates.

That may not be how some folks understand the concept of crashing, but it's definitely how most folks understand it, at least insofar as they write software.

1 service instance needs to be able to handle O(1k+) concurrent requests at scale, and a failure in any given request can't impact other in-flight requests. Those failures aren't crashes, and that software isn't crash-only -- using those terms just obfuscates things, and makes everything harder for everyone.

[jerf]

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 and you will find there are plenty of communities that do not agree that "crash == OS process terminating".

[kiitos]

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.

[jerf]

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.

[t-writescode]

It sounds like you may know a lot about this; but each actor operating in a "single-threaded", "do one thing at a time on your own" paradigm is what I'm familiar with, especially with Akka.NET, where my experience lies.

Please tell me more about its irrelevance, etc, I'd love to learn!