While he has a good point to make about the given scenarios, his complaining about loss of generality with async/await compared to generators and promise api on which async/await is built is misplaced. Loss of generality is the obvious consequence of trying to hit the most common use cases with the simplest possible syntax and semantics... i.e. you end up losing true generality.
The argument I wanted to validate here is if you can implement the very common and simple async coordination scenarios with async/await much more clearly and suitably than with CSP and if CSP itself as a model can be implemented/built using async/await (for more complicated coordination scenarios) then it seems to me that async/await would make a more universal basis for concurrency management than starting with CSP. On Sat, Oct 3, 2015 at 12:34 AM, Andrey Antukh <[email protected]> wrote: > BTW, > http://spion.github.io/posts/es7-async-await-step-in-the-wrong-direction.html > > On Mon, Sep 28, 2015 at 9:56 PM, Marc Fawzi <[email protected]> wrote: > >> << >> Is there a way to use Javascript's new 'async functions' from within >> cljs? I read that Closure compiler can transform es6/7 syntax to es5, given >> some command line flags. >> >> >> >> I meant in a way that integrates nicely with ClojureScript? >> >> The conclusion I'd like to validate is if async/await is a more universal >> pattern than CSP because it is designed for the most simple and common >> async scenarios but scales up to the more complex CSP scenario, whereas CSP >> is the other way around: designed for the most complex async coordination >> scenarios but is often applied to the most simple scenarios. >> >> >> >> >> On Mon, Sep 28, 2015 at 8:11 AM, Marc Fawzi <[email protected]> wrote: >> >>> << >>> ;; OPTION 3: using Promises;; If you're in ClojureScript, and not >>> interested in core.async, you can just use a Promise library:;; - >>> funcool/promesa is a ClojureScript wrapper of the popular Bluebird >>> JavaScript library.;; - jamesmacaulay/cljs-promises is a Promise >>> library designed to operate nicely with core.async.;; Promises take >>> care of both asynchrony and error management (they're essentially a mix of >>> Futures and Exception Monads); some may say it's convenient, others may >>> argue it's not simple. >>> >>> >> >>> >>> Is there a way to use Javascript's new 'async functions' from within >>> cljs? I read that Closure compiler can transform es6/7 syntax to es5, given >>> some command line flags. >>> >>> >>> On Sun, Sep 27, 2015 at 3:28 PM, Val Waeselynck <[email protected]> >>> wrote: >>> >>>> Adding my grain of salt: >>>> >>>> Le mercredi 16 septembre 2015 22:42:19 UTC+2, Andrey Antukh a écrit : >>>> > 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. >>>> >>>> Actually, I like error management better with core.async than with >>>> Promises / Monads, because with little effort you can use the same error >>>> constructs for synchronous and asynchronous code: >>>> https://gist.github.com/vvvvalvalval/f1250cec76d3719a8343 >>>> >>>> I do agree that promises are a more natural fit for RPC systems, >>>> because of their signal-like nature. I feel I can't really avoid RPC for >>>> building web apps, I'd be glad to know about other strategies. >>>> >>>> >>>> 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. >> > > > > -- > 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.
