This article is about actors in the Swift programming language, and I’d answer the question (“is a stateless actor pointless?”) differently: there is no such thing as a stateless actor in Swift.
Every actor in Swift conforms to the Actor protocol, which has one requirement: an instance property named `unownedExecutor`. Swift uses this property implicitly when, for example, the program calls a method on the actor from outside the actor.
There is no language (yet) which makes fine-tuned for-purpose abstractions, of all familiar kinds, both trivial to specify and performant to run/compile.
So anyone coding anything interesting is almost certainly under or over using their languages' and libraries' abstractions.
Also, for highly composable languages, where null versions of almost anything make sense: Stateless states, operationless operations, destinationless network ports, storage roots not associated with any hardware, just "0 bytes", ... all make practical sense.
Two processes intend to add two to a number.
They each read the current value.
Then they each write back the value which is two bigger then the original.
If you instead use private fields and public getters/setters, or use actors to form a protective bubble around the mutable state, you get...
If the read and the write are separate messages, i.e. the computation of the modified value happens sender-side, as in the parent example, then I don’t see how a serializing queue prevents the race condition, for two concurrent senders (clients). For that you need transactions, exactly like a database.
That's not how you would implement mutating messages in an actor system. Instead you could do either of these:
* Have an "increment" message that adds n to the current value and returns the old value.
* Have separate "read" and "write" messages, where the "write" message is parameterized by a timestamp returned by the "read" message. If the owner detects that the timestamp sent by the write is older than the most recent timestamp, it's rejected.
Because messages are handled serially, it's easy and safe to create messages that behave sanely event without explicit locks.
This is correct, but databases only help to the extent that the whole world is happy to live in your database.
As soon as you have customers (who interact via REST), or partner payment systems (e.g. stripe) you're back to:
Two customers do a GET. This gets dispatched to the DB, wrapped in a nice transaction, the transaction ends, the customers get their result.
The two customers then do a POST to set a new value. Also wrapped in a transaction.
As I pointed out above, that's not the API that would be exposed in an actor model. See in particular the timestamp-based update condition, if you're principally concerned with end-user-caused races.
Less relevant, but message queues in Erlang and related languages are typically in-memory, no DB transaction required.
Every actor in Swift conforms to the Actor protocol, which has one requirement: an instance property named `unownedExecutor`. Swift uses this property implicitly when, for example, the program calls a method on the actor from outside the actor.
https://developer.apple.com/documentation/swift/actor/unowne...
(One could also argue that, because every actor type is a reference type, every actor also has its identity as part of its state.)