There is /no/ silver bullet for the complexity of concurrency. If in a large team of uneven experience every developer is expected to address concurrency issues, then the problem is architectural.
> "share state by communicating, don't communicate by sharing state"
The elegance of this approach is very clear. But note that even in Go, when performance is critical, traditional mechanisms of locks and shared memory objects are used. (The fact that such constructs are even provided in the language should be informative to you.)
> [transparent] remoting
I recommend you read this: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7...
