4 ms·

> The Go mantra is "share by communicating, not by > sharing". Then look at all the thread examples in > "Effective Go". They all share memory, That

> The Go mantra is "share by communicating, not by > sharing". Then look at all the thread examples in > "Effective Go". They all share memory, That mantra is spoken in the context of concurrent code, not as a general axiom of the language. And I think it's remarkably well sustained in all of the concurrency examples I've seen so far. Can you be a bit more specific? > The lack of exceptions is resulting in hacks using the > "panic" mechanism to create an exception > The lack of generics is resulting in hacks using the > reflection mechanism to create generics. At the risk of making a No True Scotsman fallacy, idiomatic Go code does neither of these things.

Animats 12y ago
Sigh. First example of channels in "Effective Go" shares the list to be sorted between two goroutines. https://golang.org/doc/effective_go.html#sharing https://golang.org/doc/effective_go.html#sharing All that's sent over the channels is a flag message to start the process and report completion. Yes, there's the fanboy answer that they're not "really sharing" because both threads don't access the list at the same time. I've heard that excuse. The threads are sharing data. Deal with it. Locking is (hopefully) provided by abusing the channel mechanism to simulate a semaphore. The channel mechanism isn't doing anything here that a semaphore couldn't do better.
- xkarga00 12y ago
  Actually the Effective Go page needs to get updated. They also comment next to c <- 1 that value does not matter where the use of a struct{} channel would be more idiomatic. But still the Go mantra is valid, the means (channels) provided by the language allow for sharing by communicating and IT IS actually considered idiomatic where appropriate. Also your points about exceptions and generics are non-valid or at least very specific cases. I am working on backend stuff (mostly command-line tools) and i never felt any "lack" of them.
- skybrian 12y ago
  It's rather unfair to complain that they're simulating a semaphore when they explicitly said that this is what they're doing.

Animats 12y ago

Sigh. First example of channels in "Effective Go" shares the list to be sorted between two goroutines. https://golang.org/doc/effective_go.html#sharing https://golang.org/doc/effective_go.html#sharing All that's sent over the channels is a flag message to start the process and report completion. Yes, there's the fanboy answer that they're not "really sharing" because both threads don't access the list at the same time. I've heard that excuse. The threads are sharing data. Deal with it. Locking is (hopefully) provided by abusing the channel mechanism to simulate a semaphore. The channel mechanism isn't doing anything here that a semaphore couldn't do better.

xkarga00 12y ago
Actually the Effective Go page needs to get updated. They also comment next to c <- 1 that value does not matter where the use of a struct{} channel would be more idiomatic. But still the Go mantra is valid, the means (channels) provided by the language allow for sharing by communicating and IT IS actually considered idiomatic where appropriate. Also your points about exceptions and generics are non-valid or at least very specific cases. I am working on backend stuff (mostly command-line tools) and i never felt any "lack" of them.
skybrian 12y ago
It's rather unfair to complain that they're simulating a semaphore when they explicitly said that this is what they're doing.