Go has a very nice concurrency model which is based on light goroutines which can communicate through channels. This model provides a great abstraction which facilitates the design and synchronisation of concurrent processes. Go programs can naturally scale and fully utilise the resources on a machine.
However, there are some cases where a single machine, even the most powerful in the market, is not enough to solve certain problems. The required work in these cases, can be splitted and distributed between different nodes which can work colaboratively to compute the result. Go's concurrency model is intended to solve communication between goroutines within a single process but, as it is implemented now, it cannot be used for communicating between processes or nodes.
There have been attemps to extend the concept of channels to communicate with external goroutines, such as netchans. The Go team worked actively in the design and implementation of this concept but unfortunately, it did not get mature due to different reasons. Go's standard library provides a serialization encoding/gob and RPC net/rpc packages which allow calling functions on remote machines. The RPC library has not been improved or extended for a long time and the Go community seems to have moved into generic solutions such as Protocol Buffers and gRPC. However, when these generic libraries are used within Go, specific types, such as channel or time, cannot be used or require non trivial extensions. Also, the tooling that these libraries provide does not integrate very well with the current Go tools.
Go recently introduced the context package into the standard library, which I personally interpret as a step towards a distributed systems model. Transitive cancellations which can jump between processes are really useful, but it seems to me that most of the functionalities required to communicate between processes have not yet been defined.
The current scenario for designing distributed systems remains open to the Go community. Since Go 1 was first released in 2007, there has been an enormous advance in cloud technologies and the ecosystem around them (ie containers, cluster management). Go developers in 2017 face the challenge of having to design systems that scale into more than one node but the model or tools to implement those have not yet been defined. I personally see the announcement of Go 2 as an opportunity to come up with a consistent model that allows designing such systems.
Here might be a better alternative for RPC: https://github.com/desertbit/orbit