[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.