go - Explain: Don't communicate by sharing memory; share memory by communicating

Question

I wonder what is the most down to earth explanation of this famous quote:

Don't communicate by sharing memory; share memory by communicating. (R. Pike)

In The Go Memory Model I can read this:

A send on a channel happens before the corresponding receive from that channel completes. (Golang Spec)

There is also a dedicated golang article explaining the quote. And key contribution is a working example also by Andrew G.

Well. Sometimes too much talking around .... I have derived from the Memory Spec quotation and also by looking at the working example this:

After a goroutine1 sends (anything) to a goroutine2 via a channel, then all changes (anywhere in the memory) done by goroutine1 must be visible to goroutine2 after it received via same channel. (Golang Lemma by Me:)

Therfore I derive the Down to earth explanation of the famous quote:

To synchronize memory access between two goroutines, you don't need to send that memory via channel. Good enough is to receive from the channel (even nothing). You will see any changes that were written (anywhere) by the goroutine sending (to the channel) at the time of it's send. (Of course, assuming no other goroutines are writing to the same memory.) Update (2) 8-26-2017

I have actually two questions:

1) Is my conclusion correct?

2) Does my explanation help?

Update (1) I am assuming unbuffered channels. Lets restrict ourselves to that first to avoid overhauling ourselves with too many unknowns.

Please, let's also focus on a simple usecase of two goroutines communicating over a single channel and related memory effects and not on the best practices - that is beyond the scope of this question.

To better understand scope of my question assume that the goroutines may access any kind of memory structure - not only primitve ones - and it can be a large one, it can be a string, map, array, whatever.

Answer 1

Waitting for answers