Thanks for the insight, Andrey. It looks like async/await was originally slated for Clojure, but it later became core.async using CSP instead: http://dev.clojure.org/display/design/Async+blocks
This seems to imply that, yes, the purpose of async/await as used by C#, Python, and ES7 is fulfilled by core.async. As for the difference with Promises containing the notion of an error, it looks like David created a simple pattern for that here: http://martintrojer.github.io/clojure/2014/03/09/working-with-coreasync-exceptions-in-go-blocks/ So, I'm still confused about the intended usages, especially after reading Baldridge's comment. It may just imply that these patterns are still being worked out. On Wednesday, September 16, 2015 at 4:07:04 PM UTC-5, marc fawzi wrote: > Very educational. Thank you. Re Apples and Oranges. I had a sense of that l, > but it does not mean that many people are not using core.async in the way > Shaun documented in the gist. On many occasions, i have seen recommended by > others the use of core.async for everything async including scenarios where > it is not ideal. I think calling it core.csp would make it more clear as far > as what its purpose is. I am not entirely sure about error handling with > core.async but I've seen examples of async try/catch in that context. I see > async/await, which is syntax sugar in es7 on top of Promise, as a more > universal tool, which can be used to provide CSP functionality (see async-csp > on github) or Promise like functionality (but much nicer to use than Promise) > > Sent from my iPhone > > On Sep 16, 2015, at 1:42 PM, Andrey Antukh <[email protected]> wrote: > > > > Hi! > > > I think you are comparing apples with oranges. CSP and async/await can't be > compared directly. Async/await works with a promise (one value) abstraction > and csp works with channel abstraction (sequence). > > > It seems is an anti-pattern use channels as promises because them does not > has the notion of error. I remember that Timothy Baldridge have said > something similar about this: > > > "A sort of anti-pattern I see a lot is creating a lot of one-shot channels > and go blocks inside every function. The problem, as you see is that this > creates a lot of garbage. A much more efficient plan is to stop using > core.async as a RPC-like system, and start using it more like a dataflow > language: Identity data sources and sinks, and then transform and flow the > data between them via core.async. > It's interesting to note that core.async started as something that looked a > lot like C#'s Async/Await, but that was dropped in favor of CSP pretty > quickly. So there's reasons why the language isn't optimized for this sort of > programming style. " > > > Source: https://groups.google.com/d/msg/clojure/57ig0si3gUM/vRr-T1IaebUJ > > > > Without the intention to make spam, the funcool/cats > (https://github.com/funcool/cats) `mlet` macro does something similar in > semantics that async/await does. It there some examples using the ES6/7 > compatible promise library: > http://funcool.github.io/promesa/latest/#sugar-syntax > > > The advantage about this solution is that is generic and can be extended to > other async related abstractions as: > - JDK8 CompletableFuture's > (https://github.com/funcool/promissum/blob/master/doc/content.adoc#26-promise-chaining) > > - manifold deferred > (https://github.com/funcool/cats/blob/master/doc/content.adoc#82-manifold-deferred) > - core.async channels > (https://github.com/funcool/cats/blob/master/doc/content.adoc#81-channel) > > > Personally, I use core.async to compose different processes, but when I > interacting with async apis I almost always use promise abstraction with cats > sugar syntax. The promise abstraction semantics fits more properly in async > rpc calls that channels because it represents a "eventually available value" > and has the notion of error (unlikely core.async channels). > > > Regards. > Andrey > > > On Wed, Sep 16, 2015 at 10:30 PM, Marc Fawzi <[email protected]> wrote: > > > > > Thanks for that! > > async function baz() { > await* [foo(), bar()]; > } > (defn baz [] > (go > (doseq [c [(foo) (bar)]] > (<! c))))With the core.async case you have to define the channel c, > right? It looks cryptic compared to the es7 version. Like "go" what does go > mean, seriously? I mean in terms of its English language context. Go does not > convey async. And what the heck is <! Are we using bash or something? Some > kind of inverted redirection? I guess you can have macros that would make it > look just as comprehensible as the es7 async version so people coming into > CLJS won't be turned off by the crazy looking syntax and the exposed low > level semantics. Maybe a bunch of core.async macros that expose common use > cases in a way that anyone can understand without even having to understand > CSP basics. In my team, everyone gets the es7 version of things but despite > having been CLJS users for 6 months now, no one understands how to use > core.async. I've had to play with it in different languages before I realized > how powerful it is to have in your toolset to manage complex (potentially > dynamic) coordination patterns between async processes but our use cases in > the UI have yet to beyond the very simple use cases your gist shows which are > (without use of macros) much easier to understand using es7 async > functions.If macros can solve the "comprehensibility" problem for the common > use cases then maybe something that would provide es7 async like library for > cljs that gives you defnasync and await Syntax and semantics can then be so > simple while the underlying system remains so powerful and in that case you > could have core.async be bundled with those macros thus allowing easy access > to common async patterns without the Go syntax obfuscating things and making > it seem complicated as well as too noisy syntax wise for the most common > tasks > > Sent from my iPhone > > > > On Sep 15, 2015, at 9:38 PM, Shaun LeBron <[email protected]> wrote: > > > ES7 vs core.async (gist): > https://gist.github.com/shaunlebron/d231431b4d6a82d83628 > > On Tuesday, September 15, 2015 at 3:51:06 PM UTC-5, marc fawzi wrote: > Well the title gives that impression and I regret having chose to do that :) > > But if you read the content i am asking the question if Async functions in > es7 can be used to build a performant and faithful version of CSP (github: > aysnc-csp) and also be useful for common tasks like the simple server request > scenario I mentioned then why wouldnt we want to think of CSP as just one > pattern not the One True Pattern for async. Right now core.async is being > used and or recommended for everything async and I am asking if that is ideal > and if CLJS can allow itself to grow beyond this one particular pattern when > it comes to async. The first thing would be renaming core.async to core.csp > and promoting choice when it comes to async patterns. As it is right now, > every time someone has an async design problem core.async is recommended as a > solution regardless of whether or not it's the best fit solution. If you have > a hammer... > > That's the scope. Not es7 vs core.async and I'm sorry for the stupid title. > > Sent from my iPhone > > On Sep 15, 2015, at 8:32 AM, Johann Bestowrous <[email protected]> wrote: > > At a high level, I think it's pretty important to note that you are comparing > a language spec to a library. > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > > > > > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at http://groups.google.com/group/clojurescript. > > > > > > -- > > > > > > Andrey Antukh - Андрей Антух - <[email protected]> > http://www.niwi.nz > > https://github.com/niwinz > > > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
