3 ms·

I think Go adds even more complexity to concurrency by pushing the CSP model. CSP is hard for many problems where classic shared-memory using locks and atomics

I think Go adds even more complexity to concurrency by pushing the CSP model. CSP is hard for many problems where classic shared-memory using locks and atomics are well defined (think of classic concurrency programming textbooks).

klodolph 6y ago
Go provides all of that, you have sync.Mutex and sync.Cond, and you are of course free to use them. People do use them in practice, precisely because some code is easier to write that way. Saying that Go "adds even more complexity to concurrency" doesn't scan. It lets you write code using whichever model you prefer--CSP or mutexes. It is definitely true that CSP is hard for many problems... but locks and shared memory is also hard for many problems. There is no silver bullet, so you need both.
- spyspy 6y ago
  Pretty much every time I’ve pulled out a channel in Go I end up rewriting it to just use a mutex, or even easier, write to individual indices in a slice.
- diehunde 6y ago
  You forgot to quote the most relevant part of my statement: "...by pushing the CSP model." Of course you can do whatever you want, but Go is a very opinionated language and there's an opinionated community behind it. Which it's fine. But then when you ask "how to do X using locks," the only thing people respond is the mantra of "don't communicate by sharing, share by communicating". Which doesn't help in any way. Then people ask complex questions about using channels and others say "why don't you just use locks?" That's why I think Go adds more instead of alleviating the complexity of writing concurrent programs.
  - klodolph 6y ago
    > You forgot to quote the most relevant part of my statement: "...by pushing the CSP model." I didn't quote that part because it's the most nonsensical part of the comment. You've apparently been frustrated by your interactions with the members of the community and that's a fair complaint, but you haven't translated that complaint into a criticism of the Go language itself. My experience is--CSP is a reasonable default, and "select" is a really nice language feature to have around, and mutexes / condition variables are still available when you need them. Mutexes aren't a good substitute for CSP and CSP isn't a good substitute for mutexes. You should have both available.
    - diehunde 6y ago
      That's exactly my criticism. You don't need both. You only add confusion by having both. Just stick to one and improve it. Most successful languages don't have native support for two concurrency models and people have built amazing concurrent software with them. Now with Go, you have this extra problem of "should I be using channels or locks?"
      - klodolph 6y ago
        In my experience, you definitely want to have both options available. Like you said: > CSP is hard for many problems where classic shared-memory using locks and atomics are well defined (think of classic concurrency programming textbooks). This isn't a problem with Go's particular flavor of CSP, this is just a fact--it can be hard to translate simple modules that use locks into modules that use a CSP paradigm. > Now with Go, you have this extra problem of "should I be using channels or locks?" I think you're arguing against yourself here... if it's important to answer the question "should I be using channels or locks?" correctly, then wouldn't you be in a bad situation if the language only provided channels or only provided locks? This is no different from the problem of "should I use recursion or iteration?" or "should I use a tree or a hash table?" Some times, either option is workable, but at other times, one of the options is better than the other. CSP versus locks is the same thing, it's just another decision you have to make when programming.
chrisseaton 6y ago
CSP also encourages writing very racy programs, as the order in which messages arrive in queues can be non-deterministic.
- pkaye 6y ago
  What are the alternatives that are deterministic?
  - chrisseaton 6y ago
    Structured concurrency - fork and join models, or dataflow models, for example. Or clocked models like a physical circuit.
    - joubert 6y ago
      Fork-join and dataflow models are parallel computing solutions. Are you suggesting that one should strive to solve concurrency problems with parallel computing approaches?
      - valenterry 6y ago
        No they are not. You can easily do concurrency with a fork-join approach on just on thread (no parallel execution). fork-join in the browser with e.g. V8 as the runtime is a good example of that.
        aarongolliver 6y ago
        I wonder how many years of fork() we had before someone finally had a second core to run things on.
      - CyberDildonics 6y ago
        This is just a nonsense semantic game. Everything gets synchronized or serialized at some point, even if it is hardware that does it.
initplus 6y ago
In theory I like channels, in practice I find them challenging to program with. The fact that only the sender can safely close a channel is frequently frustrating.
- cle 6y ago
  I think the Go docs can be more discerning about when to use channels and when to use shared memory. The broad advice of "share by communicating" is too broad, too many people learn Go and think they need to use channels and CSP everywhere, and then quickly realize that they've over-engineered their program. I typically use shared memory by default (mostly mutexes and waitgroups), and generally only use channels when I'm working with task queues, which is where they really shine.

klodolph 6y ago

Go provides all of that, you have sync.Mutex and sync.Cond, and you are of course free to use them. People do use them in practice, precisely because some code is easier to write that way. Saying that Go "adds even more complexity to concurrency" doesn't scan. It lets you write code using whichever model you prefer--CSP or mutexes. It is definitely true that CSP is hard for many problems... but locks and shared memory is also hard for many problems. There is no silver bullet, so you need both.

spyspy 6y ago
Pretty much every time I’ve pulled out a channel in Go I end up rewriting it to just use a mutex, or even easier, write to individual indices in a slice.
diehunde 6y ago
You forgot to quote the most relevant part of my statement: "...by pushing the CSP model." Of course you can do whatever you want, but Go is a very opinionated language and there's an opinionated community behind it. Which it's fine. But then when you ask "how to do X using locks," the only thing people respond is the mantra of "don't communicate by sharing, share by communicating". Which doesn't help in any way. Then people ask complex questions about using channels and others say "why don't you just use locks?" That's why I think Go adds more instead of alleviating the complexity of writing concurrent programs.
- klodolph 6y ago
  > You forgot to quote the most relevant part of my statement: "...by pushing the CSP model." I didn't quote that part because it's the most nonsensical part of the comment. You've apparently been frustrated by your interactions with the members of the community and that's a fair complaint, but you haven't translated that complaint into a criticism of the Go language itself. My experience is--CSP is a reasonable default, and "select" is a really nice language feature to have around, and mutexes / condition variables are still available when you need them. Mutexes aren't a good substitute for CSP and CSP isn't a good substitute for mutexes. You should have both available.
  - diehunde 6y ago
    That's exactly my criticism. You don't need both. You only add confusion by having both. Just stick to one and improve it. Most successful languages don't have native support for two concurrency models and people have built amazing concurrent software with them. Now with Go, you have this extra problem of "should I be using channels or locks?"
    - klodolph 6y ago
      In my experience, you definitely want to have both options available. Like you said: > CSP is hard for many problems where classic shared-memory using locks and atomics are well defined (think of classic concurrency programming textbooks). This isn't a problem with Go's particular flavor of CSP, this is just a fact--it can be hard to translate simple modules that use locks into modules that use a CSP paradigm. > Now with Go, you have this extra problem of "should I be using channels or locks?" I think you're arguing against yourself here... if it's important to answer the question "should I be using channels or locks?" correctly, then wouldn't you be in a bad situation if the language only provided channels or only provided locks? This is no different from the problem of "should I use recursion or iteration?" or "should I use a tree or a hash table?" Some times, either option is workable, but at other times, one of the options is better than the other. CSP versus locks is the same thing, it's just another decision you have to make when programming.

chrisseaton 6y ago

CSP also encourages writing very racy programs, as the order in which messages arrive in queues can be non-deterministic.

pkaye 6y ago
What are the alternatives that are deterministic?
- chrisseaton 6y ago
  Structured concurrency - fork and join models, or dataflow models, for example. Or clocked models like a physical circuit.
  - joubert 6y ago
    Fork-join and dataflow models are parallel computing solutions. Are you suggesting that one should strive to solve concurrency problems with parallel computing approaches?
    - valenterry 6y ago
      No they are not. You can easily do concurrency with a fork-join approach on just on thread (no parallel execution). fork-join in the browser with e.g. V8 as the runtime is a good example of that.
      - aarongolliver 6y ago
        I wonder how many years of fork() we had before someone finally had a second core to run things on.
    - CyberDildonics 6y ago
      This is just a nonsense semantic game. Everything gets synchronized or serialized at some point, even if it is hardware that does it.

initplus 6y ago

In theory I like channels, in practice I find them challenging to program with. The fact that only the sender can safely close a channel is frequently frustrating.

cle 6y ago
I think the Go docs can be more discerning about when to use channels and when to use shared memory. The broad advice of "share by communicating" is too broad, too many people learn Go and think they need to use channels and CSP everywhere, and then quickly realize that they've over-engineered their program. I typically use shared memory by default (mostly mutexes and waitgroups), and generally only use channels when I'm working with task queues, which is where they really shine.