4 ms·

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

• 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.