An async/await example of the simple cases where we'd normally use
Promise/Future
async function() { try { await* [asyncOp1(), asyncOp()2, ...] } catch (e) {
.... } }
As far as I know, with CSP you have to setup a channel and then implement an
async try/catch.
So given that we can build CSP model using async/await (see async-csp on
github) then I would say that async/await is the more universal base. CSP can
be seen as a higher level abstraction.
Sent from my iPhone
> On Sep 18, 2015, at 5:48 AM, Marc Fawzi <[email protected]> wrote:
>
> I can also imagine a parallel universe where async/await was adopted for
> Clojure/Script and someone built a CSP library for Clojure/Script based on
> it. The syntax as well as the semantics for the raw async/wait (as opposed to
> any CSP implementation based on it) is so much more concise and
> comprehensible than core.async syntax and semantic for the simple use cases
> where we currently (in JS es6, Java, Scala and other languages) use
> Promises/Futures. For the CSP case, we can have CSP based on async/await (see
> async-csp on github) without the crazy Go inspired syntax.
>
> And when you say that CSP covers all async scenarios you neglect to
> acknowledge that for some scenarios async/await would be far simpler,
> especially if you add async error handling to it! I can't believe that this
> is too hard to see that. Or am I missing something?
>
>
> Sent from my iPhone
>
>> On Sep 17, 2015, at 9:34 AM, Shaun LeBron <[email protected]> wrote:
>>
>> 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.
--
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.
