[bkirkbri]

It's true that out of the box core.async is MUCH nicer to use with existing asynchronous IO APIs. My limited experience has shown that you'll want to wrap your synchronous IO operations to play well with core.async. This generally means queueing work in an operation-local (or subsystem-local) threadpool and providing an async API for interfacing with via core.async.

The next step is deciding on how to expose the asynchronicity. I chose to accept / return channels rather than callbacks, because... well... wrapping your sync code in a callback-based async API just to glue them together with go blocks and channels seemed backward to me. :)

I think this "next level up" from the foundation of core.async has potential for some really great solutions and I'm dying to see what Tim and others will come up with...