Actors in principle (isolated objects assigned to threads) sound great until you need to SHARE data, then you enter a new universe of compromises where you need locking mechanisms (for performance), but no language semantics support it natively. Pony introduced reference capabilities but that still created a cludge for those times you needed synchronous access. There is no model yet where locking primitives are associated with resource handles.
Erlang OTP 21.2 introduced the idea of `persistent_term`, which is a data structure any process can read from at the expense of being costly to modify. This provides a nice alternative to locks, since you can have a single actor/process responsible for handling writes (and deciding when to flush those writes, triggering a GC pause on processes depending on the term) but any number of actors reading from that persistent term at full-speed.
> ... sound great until you need to SHARE data ...
If by "share" you mean one writer and others with read-only access, then staleness of data is a question. In java we have volatile for that, I think there is a similar keyword in C++. However, you'll have to maintain the invariant of "one writer and others with read-only access". If you don't need absolute latest version, you can do message passing/pubsub etc.
If by "share" you mean multiple writers, I'll have to question your design decision. Why do multiple threads have to write to same memory location? Most of the time, you can get away with partitioning/sharding.
Unfortunately, our objects are not isolated, they interact with the world, and often need to be shared when we cannot copy the resource (performance). Eg. a (partitioned) rendering surface may be written simultaneously, a physics engine needs to know what objects are in the game world, multiple bank accounts need to be updated simultaneously, etc. By design is not always possible to sequence, some transactions must be atomic across multiple objects.
Yes they are, atom is in isolation, cell has membrane, we have a body we have isolation and encapsulation in physics/chemistry/biology. In actor model message passing is interaction. Since you mentioned game, check out https://github.com/aeplay/kay, which is the isolation "objects" for https://github.com/citybound/citybound "physics engine". On multiple bank accounts, well an account is an actor, so there is no problem there, please have a look at http://proto.actor/blog/2017/06/24/money-transfer-saga.html
