I would liken it to the Game of Go (pun intended). You have a very small number of elements: chan, go, >!, <!, alts!. The learning curve is a bit steep because you have invest some time unlearning patterns you've picked up from traditional UI programming. But once you cross over the hump and you realize what is possible with just these few tools a whole vista of possibilities opens up. I'm sure the fans of go-lang would agree.

Another analogy - Alan Kay compares software engineering to architecture and how so much engineering is brute force (think pyramids). core.async (really CSP) is like an arch (think gothic cathedral). Common UI patterns no longer seem arduous - and UI patterns which once seemed far out reach can be accomplished with a reasonable amount of engineering effort.

Thanks - I like those analogies. I want to invest some time to see if the unlearning works for me. Most times when converting to a higher level way of doing something it eventually does.

Also - thanks for all the awesome core.async gists - I feel like I want to take a geek sabbatical just so I can study them :)

> this is harder to read than the callback approach right now

Why do you think this is (I'm asking honestly, not trying to be snarky). Is it because you are not familiar with reading Lisp? The notation used to access channels is confusing? Unfamiliarity with the go-block concept?

It took me a while to fully internalize the combination of syntax and power of go blocks, but now that I have reading core.async code (I have not yet had a need to actually use them, and no time to port an existing codebase) is much easier.

I question whether the statement that callbacks are easier to read and understand is merely due to being accustomed to them. Core.async represents a radical departure from existing designs, and that can be jarring. Does this mean better syntactic sugar won't be created as developers gain experience? Or course not.

Yeah, I think it's just unfamiliarity with this approach + deep familiarity with the callback approach, and I'm merely reporting my experience and not making a judgement on the approach in general. Sometimes when I see a callback it's a helpful signal that something asynchronous is happening - it's good to know. That said, with some further accustoming to the channel approach, it will probably both read naturally and be apparent where the async stuff is happening.