4 ms·

This is a frustrating and overly-exasperated post which reaches conclusions that have always been part of the Go canon. APIs should be designed synchronously, a

This is a frustrating and overly-exasperated post which reaches conclusions that have always been part of the Go canon. APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose -- yes! Channels are useful in some circumstances, but if you just want to synchronize access to shared memory (like the author's example) then you should just use a mutex -- yes! These are well understood truths. Novices to the language have a tendency to overuse channels. Here is Andrew Gerrand addressing precisely this point two years ago at GopherCon: https://www.youtube.com/watch?v=u-kkf76TDHE&t=815 https://www.youtube.com/watch?v=u-kkf76TDHE&t=815 Neither the referenced performance characteristics via Tyler Treat, nor the FUD surrounding channel-based program architecture, invalidate channels generally. One does have to think carefully about ownership hierarchies: only one goroutine gets to close the channel. And if it's in a hot loop, a channel will always perform worse than a mutex: channels use mutexes internally. But plenty of problems are solved very elegantly with channel-based CSP-style message passing. It's unfortunate that articles like this are written and gain traction. The explicit instruction to [new] Go programmers is that they should avoid channels, even that they are badly implemented, and both of those things are false.

mordocai 11y ago
As a non-go programmer, I'm pretty sure the author made some very good objective arguments that channels are in fact badly implemented.
- sagichmal 11y ago
  Read Tyler's original article for a less FUDdy take on it. Channels are always slower than mutexes, which is obvious when you understand their implementation. They are definitely not badly implemented as a general rule.
  - zeeboo 11y ago
    The api definitely is badly implemented and makes them hard to use. That's the point of the post. There are design decisions around channels (sends panicing, close panicing, nil channels blocking) that make them hard to understand, follow, and compose concurrent solutions.
    - sagichmal 11y ago
      I'm sorry, but I don't agree with any of your assertions. The constraints on channels are there not as an accident of a bad implementation, but as deliberate decisions to enforce a certain set of design contracts. Panics on invalid channel operations enforce those contracts. That nil channels block is actually an incredibly handy feature: see e.g. https://github.com/streadway/handy/blob/b8cb168/breaker/breaker.go#L126 https://github.com/streadway/handy/blob/b8cb168/breaker/brea... Without exception, hitting one of these corner cases exposes an error in design, from Go's perspective on CSP. You can disagree with that perspective on a subjective basis ("hard to understand") -- but you can't lift that opinion to objective fact, and you certainly can't claim these artifacts of design as evidence of incompetence or neglect.
      - mordocai 11y ago
        While I agree all of this is subjective, I would argue that something being composed of "deliberate decisions to enforce a certain set of design contracts" doesn't mean those decisions nor the design contracts are good. Nor does it automagically make a good implementation. In addition, making bad design decisions that you think are good is actually one of the best types of evidence for incompetence (though not neglect, in this case). I don't personally have enough data to have a strong opinion on where Go channels falls here, but I don't think any of your arguments here have any bearing on the idea that Go's channel implementation is bad.
        AnimalMuppet 11y ago
        But using something in the way it was not intended to be used, and then complaining that it works badly, is evidence of incompetence on the part of the user, not the designer. > I don't personally have enough data to have a strong opinion on where Go channels falls here, but I don't think any of your arguments here have any bearing on the idea that Go's channel implementation is bad. If sagichmal is correct, zeeboo is trying to use channels in a way that they were explicitly not designed to be used. That makes zeeboo's criticism very likely to be invalid. (It is the one who uses them as they were designed to be used who knows what the actual problems with the design are.)
- voidlogic 11y ago
  Hammers make poor screw drivers. Mutexes, atomic integer operations, and channels (buffered and unbuffered) all have their place. You will think any of these is "badly implemented" if you choose the wrong tool for the job.
bad_user 11y ago
> APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose Wait, why would you say that? In general, if "orchestrating concurrency" involves guarding access to shared mutable state, then you can't orchestrate it at the callers site. It would be a massive encapsulation leak, because synchronization is not composable, requires special knowledge, plus you don't necessarily know how to synchronize unless you have knowledge about internals. Furthermore, because it is after the fact, your only choice of handling it is by means of mutexes, which has really terrible performance characteristics. Even if you could do ordering by other means, you end up paying the price of LOCK XCHG or whatever mutexes translate to, not to mention that you'll have problems if you want (soft) real-time behavior, because now you can end up with both dead-locks and live-locks. And this brings us to another problem. If you end up doing such synchronization in Go, then Go's M:N multi-threading ends up doing more harm than good, because if you need such synchronization, you also need to fine tune your thread-pools and at this point 1:1 would be better. On top of 1:1 platforms you can build M:N solutions, but it doesn't work well in the other direction. > Novices to the language have a tendency to overuse channels Novices to software development have a tendency to overuse mutexes as well.
- sagichmal 11y ago
  > In general, if "orchestrating concurrency" involves guarding access to shared mutable state, then you can't orchestrate it at the callers site. Shared mutable state is generally behind an API boundary. I'm talking about the exported method set of that API. That is, func (f *Foo) Update(i int) (int, error) // yes func (f *Foo) Update(i int) (<-chan int, error) // no func (f *Foo) Update(i int, result chan<- int) error // no
- jerf 11y ago
  "In general, if "orchestrating concurrency" involves guarding access to shared mutable state, then you can't orchestrate it at the callers site." What this generally means in Go is that it is an antipattern for your library to provide something like "a method that makes an HTTP request in a goroutine". In Go, you should simply provide code that "makes an HTTP request", and it's up to the user to decide whether they want to run that in a goroutine. The rest of what you're talking about is a completely different issue. Channels are smelly in an API. IIRC in the entire standard library there's less than 10 functions/methods that return a channel. But the use case does occasionally arise.
mordocai 11y ago
In addition, the author points out existing go libraries that people use that use channels when they shouldn't, so apparently the go language community needs more people pointing out that this is a bad idea. (I decided to make a new comment rather than edit my existing comment)
admiun 11y ago
"APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose" Just to add to this, I found the blog post he mentions[1] towards the bottom that supports this conclusion a really good read. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
jtolds 11y ago
This post was written primarily as a response to http://www.informit.com/articles/article.aspx?p=2359758 http://www.informit.com/articles/article.aspx?p=2359758, which, when it came out last June, frustrated me to no end. It then sat in my drafts folder for months until patiently attempting to bring another experienced programmer, new-to-Go, up to speed on best practices. If it truly is the accepted best practice for novices to avoid channels, then that PR campaign has been tried and found lacking. EDIT: whoops, read parent wrong.
- d_theorist 11y ago
  I think you have the sense of the last sentence of the parent comment backwards.
  - jtolds 11y ago
    Oh, so I did.
deleted 11y ago
[deleted]
nfirvine 11y ago
"Novices to the language have a tendency to overuse channels." "The explicit instruction to [new] Go programmers is that they should avoid channels... [is] false." -- Isn't this a contradiction?

mordocai 11y ago

As a non-go programmer, I'm pretty sure the author made some very good objective arguments that channels are in fact badly implemented.

sagichmal 11y ago
Read Tyler's original article for a less FUDdy take on it. Channels are always slower than mutexes, which is obvious when you understand their implementation. They are definitely not badly implemented as a general rule.
- zeeboo 11y ago
  The api definitely is badly implemented and makes them hard to use. That's the point of the post. There are design decisions around channels (sends panicing, close panicing, nil channels blocking) that make them hard to understand, follow, and compose concurrent solutions.
  - sagichmal 11y ago
    I'm sorry, but I don't agree with any of your assertions. The constraints on channels are there not as an accident of a bad implementation, but as deliberate decisions to enforce a certain set of design contracts. Panics on invalid channel operations enforce those contracts. That nil channels block is actually an incredibly handy feature: see e.g. https://github.com/streadway/handy/blob/b8cb168/breaker/breaker.go#L126 https://github.com/streadway/handy/blob/b8cb168/breaker/brea... Without exception, hitting one of these corner cases exposes an error in design, from Go's perspective on CSP. You can disagree with that perspective on a subjective basis ("hard to understand") -- but you can't lift that opinion to objective fact, and you certainly can't claim these artifacts of design as evidence of incompetence or neglect.
    - mordocai 11y ago
      While I agree all of this is subjective, I would argue that something being composed of "deliberate decisions to enforce a certain set of design contracts" doesn't mean those decisions nor the design contracts are good. Nor does it automagically make a good implementation. In addition, making bad design decisions that you think are good is actually one of the best types of evidence for incompetence (though not neglect, in this case). I don't personally have enough data to have a strong opinion on where Go channels falls here, but I don't think any of your arguments here have any bearing on the idea that Go's channel implementation is bad.
      - AnimalMuppet 11y ago
        But using something in the way it was not intended to be used, and then complaining that it works badly, is evidence of incompetence on the part of the user, not the designer. > I don't personally have enough data to have a strong opinion on where Go channels falls here, but I don't think any of your arguments here have any bearing on the idea that Go's channel implementation is bad. If sagichmal is correct, zeeboo is trying to use channels in a way that they were explicitly not designed to be used. That makes zeeboo's criticism very likely to be invalid. (It is the one who uses them as they were designed to be used who knows what the actual problems with the design are.)
voidlogic 11y ago
Hammers make poor screw drivers. Mutexes, atomic integer operations, and channels (buffered and unbuffered) all have their place. You will think any of these is "badly implemented" if you choose the wrong tool for the job.

bad_user 11y ago

> APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose Wait, why would you say that? In general, if "orchestrating concurrency" involves guarding access to shared mutable state, then you can't orchestrate it at the callers site. It would be a massive encapsulation leak, because synchronization is not composable, requires special knowledge, plus you don't necessarily know how to synchronize unless you have knowledge about internals. Furthermore, because it is after the fact, your only choice of handling it is by means of mutexes, which has really terrible performance characteristics. Even if you could do ordering by other means, you end up paying the price of LOCK XCHG or whatever mutexes translate to, not to mention that you'll have problems if you want (soft) real-time behavior, because now you can end up with both dead-locks and live-locks. And this brings us to another problem. If you end up doing such synchronization in Go, then Go's M:N multi-threading ends up doing more harm than good, because if you need such synchronization, you also need to fine tune your thread-pools and at this point 1:1 would be better. On top of 1:1 platforms you can build M:N solutions, but it doesn't work well in the other direction. > Novices to the language have a tendency to overuse channels Novices to software development have a tendency to overuse mutexes as well.

sagichmal 11y ago
> In general, if "orchestrating concurrency" involves guarding access to shared mutable state, then you can't orchestrate it at the callers site. Shared mutable state is generally behind an API boundary. I'm talking about the exported method set of that API. That is, func (f *Foo) Update(i int) (int, error) // yes func (f *Foo) Update(i int) (<-chan int, error) // no func (f *Foo) Update(i int, result chan<- int) error // no
jerf 11y ago
"In general, if "orchestrating concurrency" involves guarding access to shared mutable state, then you can't orchestrate it at the callers site." What this generally means in Go is that it is an antipattern for your library to provide something like "a method that makes an HTTP request in a goroutine". In Go, you should simply provide code that "makes an HTTP request", and it's up to the user to decide whether they want to run that in a goroutine. The rest of what you're talking about is a completely different issue. Channels are smelly in an API. IIRC in the entire standard library there's less than 10 functions/methods that return a channel. But the use case does occasionally arise.

mordocai 11y ago

In addition, the author points out existing go libraries that people use that use channels when they shouldn't, so apparently the go language community needs more people pointing out that this is a bad idea. (I decided to make a new comment rather than edit my existing comment)

admiun 11y ago

"APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose" Just to add to this, I found the blog post he mentions[1] towards the bottom that supports this conclusion a really good read. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

jtolds 11y ago

This post was written primarily as a response to http://www.informit.com/articles/article.aspx?p=2359758 http://www.informit.com/articles/article.aspx?p=2359758, which, when it came out last June, frustrated me to no end. It then sat in my drafts folder for months until patiently attempting to bring another experienced programmer, new-to-Go, up to speed on best practices. If it truly is the accepted best practice for novices to avoid channels, then that PR campaign has been tried and found lacking. EDIT: whoops, read parent wrong.

d_theorist 11y ago
I think you have the sense of the last sentence of the parent comment backwards.
- jtolds 11y ago
  Oh, so I did.

deleted 11y ago

[deleted]

nfirvine 11y ago

"Novices to the language have a tendency to overuse channels." "The explicit instruction to [new] Go programmers is that they should avoid channels... [is] false." -- Isn't this a contradiction?