[jws]

Just yesterday I was staring at some of my go code thinking that channels are the "goto" of concurrency. You can make just about anything with them, but to understand code you have to read it all, hold it in your head, and reason about all possible outcomes. In the '60s that's how flow of control was done. As the '70s went by "structured programming" came in and exotic things like while loops, switch statements, and functions that you could only enter at the top (so limiting!) became the norm.

This post proposes a level of abstraction to take a common 10 line idiom and abstract it to a word. I'd much rather read code with the abstraction. (In this case it is clean to read, but there are many complicated patterns in common use involving auxiliary chans for cancellation and timeouts.) Sadly, this is where it collides with the go language designers. Go is anti-abstraction by design. If you don't like that then you descend into interface{} hell and manual runtime type checking, or change languages, or just repeat yourself a lot and pray you get the fiddly bits right each time.

[zzzcpan]

Oh, they use abstractions a lot, just not the flow control ones, mainly objects. Like sync.WaitGroup mentioned here is an object and is a completely brain dead choice for this kind of thing. Some form of parallel map() instead would be much easier to understand and to reason about, for example: http://play.golang.org/p/4I-uBJ1Tce

Anyways, I mostly agree, just not generally over abstractions, but more in the context of proper flow control abstractions.

[namelezz]

Is it easy to use channels for concurrency in UI development. I believe most UI developments use callbacks, such as onClick, handleClick...