From akka documentation:
Unlike objects, actors encapsulate not only their state but their execution. Communication with actors is not via method calls but by passing messages. While this difference may seem minor, it is actually what allows us to break clean from the limitations of OOP when it comes to concurrency and remote communication.
I understand the bit about concurrency, but am not very clear about remote communcation.
Remote communication is essentially always asynchronous message passing.
In OOP, inter-object communication is typically accomplished via synchronous method calls (i.e. the call blocks until it has a result). Thus in order to communicate with remote objects, one must either use an RPC mechanism which wraps the underlying asynchronous message passing to present a synchronous interface or use something like futures to make the interface a hybrid of synchronous and asynchronous. Both approaches add a lot of complexity: RPC mechanisms tend to add a lot of hidden complexity and futures tend to add a lot of apparent complexity.
For actors, the communication is asynchronous message passing. The only conceptual difference between sending a message to an Akka actor running in the same JVM as the sender and an Akka actor running in a different JVM (same machine or different machine) is that in the former case one can optimize by not serializing the message. Beyond the intrinsic overhead of getting two different JVMs to communicate, there's no added complexity in making an actor communicate remotely. If two actors can successfully work together locally to make up a working system, it's virtually certain that they can easily (e.g. with Akka remoting) work together even when they need to communicate over a network.