5 ms·

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

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.

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.