Interesting. So you think it is a general safety advisory (which would apply to any language) to use synchronization (ex: mutex or channel) and not a more focused push to use channels? Hmmm... I didn't understand it that way. I thought that "communicate" was a reference to the "C" in CSP. It never crossed my mind that it would mean "use synchronization".
The context of the Go FAQ section which includes the proverb discourages mutexes (with no mention of when they should or should not be used). The two links it provides bolster this and only provide examples using channels. The wiki article MutexOrChannel starts off with the proverb then immediately follows with "That said, Go does provide traditional locking mechanisms in the sync package." Why the need to say this if the moto was meant to include the sync methods, too? Everything I recall reading or listening to which references the proverb seems to continue in this theme to avoid locking. Here's a rather explicit one from https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions: " Don’t communicate by sharing memory, share memory by communicating. Our first proverb–don’t mediate access to shared memory with locks and mutexes, instead share that memory by communicating." Also, in Rob Pike's talk "Go Proverbs" at Gopherfest on 11/18/2015 he talks about this proverb. He defines "sharing memory by communicating" as "passing on a channel the address of a data structure or an object ...". So I don't think that I'm alone in thinking that the focus of the proverb is to use channels to share memory, rather than any other way. And I find this somewhat wrong and certainly confusing. Am I really alone in this? John John Souvestre - New Orleans LA -----Original Message----- From: Ian Lance Taylor [mailto:i...@golang.org] Sent: 2017 August 18, Fri 15:14 To: John Souvestre Cc: golang-nuts Subject: Re: [go-nuts] Go channels overused and hyped? On Fri, Aug 18, 2017 at 12:02 PM, John Souvestre <j...@souvestre.com> wrote: > > I think that both of the suggestions below are great. But I�m left > wondering about the Go mantra > > > > Do not communicate by sharing memory. Instead, share memory by > communicating. > > > > What does it say? It starts off with communicating as the goal, but doesn�t > tell you how to do it. Then sharing memory is the goal and the solution it > provides (communicating) is only right some of the time. > > > > Am I missing something? Should this be replaced? As I see it, the point of the proverb is to focus on having goroutines use explicit communication mechanisms, such as channels and mutexes, to hand control of an area of memory over to another goroutine. An example of communicating by sharing memory would having one goroutine poll a memory location that is then changed by a different goroutine. As a general guideline, prefer explicit communication mechanisms. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
