[valand]

> You can't accidentally share memory, you can't bind state through a function call - you have to send a message, and await a response.

These are not strictly a "program on network vs program not on network" issue. "Accidentally sharing memory" can be solved by language design. It is correct that a system that is supposedly designed as inter-actor communication is not ideal when designed and written in a "function call-like" manner, but erlang only partially solves this phenomena by enforcing a type of architecture, which locks away the mentioned bad practice.

> ...despite being extremely similar to service oriented architecture in many ways. Why? Because putting things behind a network can, counter intuitively, lead to more resilient systems.

This is a strange logic. Resilient system is usually achieved by putting a service/module/functionality/whatever in a network of replications, meanwhile service oriented architecture talks about loosening the coupling between different computers that acts differently.

I do agree on microservice != turn function calls into distributed computing problems.

It MAY happen to systems eagerly designed with microservice architecture without a proper prior architectural validations, but it is not always the case.

[staticassertion]

> "Accidentally sharing memory" can be solved by language design.

For sure - I am definitely not trying to say that there is "one true approach".