Actors/messaging doesn't imply a remote-backend architecture. It only implies messaging and mutually-exclusive _writable_ state.
GUIs is a poor example as they are inherently single-threaded frontends so performing simultaneous actions is already often implemented utilizing message-passing to backend threads which report back to a single-threaded event-loop. That architecture can be local, backend "threads" or remote processes, as it doesn't much matter to the GUI.
With regard to in-memory persistence, again, you almost certainly would not copy data per thread. For a situation like you're describing, a Redis-like architecture is all you need with a few atomic primitives. But, again, incredibly easy to implement in Go and is certainly _not_ rocket science.
Of course, someone is going to still be using locks, but it's a diminishing number of developers that need to code at that level since there are better higher-level techniques that serve many purposes and protect against many types of errors.
GUIs is a poor example as they are inherently single-threaded frontends so performing simultaneous actions is already often implemented utilizing message-passing to backend threads which report back to a single-threaded event-loop. That architecture can be local, backend "threads" or remote processes, as it doesn't much matter to the GUI.
With regard to in-memory persistence, again, you almost certainly would not copy data per thread. For a situation like you're describing, a Redis-like architecture is all you need with a few atomic primitives. But, again, incredibly easy to implement in Go and is certainly _not_ rocket science.
Of course, someone is going to still be using locks, but it's a diminishing number of developers that need to code at that level since there are better higher-level techniques that serve many purposes and protect against many types of errors.