On Sat, Oct 3, 2015 at 11:15 AM, Marc Fawzi <[email protected]> wrote:
> 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. > I understand and I'm pretty convinced that csp as is, is a concurrency model and can be implemented in different ways. I think that the current async/await approach is slightly coupled to the promise. Obviously if you decouple it from promise, a csp can be implemented using async/await. In fact, async/await is just a sugar syntax. The main error of the ES7 async/await is that is hard coupled with promises. With the link that I have shared in previous email, I mean that generators are more versatile and also offers the same features that async await. CSP like abstraction is easily can be implemented on top of generators/coroutines: https://github.com/ubolonton/js-csp. Furthermore, in funcool/cats[1], we have implemented an other way to do it with more clojure like syntax: `mlet` and `alet` macros. They looks very familiar because the aspect is like a normal clojure let. The difference is that them are implemented in terms of abstractions. Imagine this example function: async function doFoo() { const x = await doFirstThing() const y = await doSecondThing(); return x + y; } With cats abstraction, you do not need any compiler support for implement async/await, just use a familiar syntax. This is equivalent code in clojure/clojurescript that does exactly the same thing: (require '[cats.core :as m]) (defn do-foo [] (m/mlet [x (do-first-thing) y (do-second-thing)] (m/return (+ x y)))) But both, the async/await, and mlet macro has one disadvantage: the code is inherently serial. But in a lot of circumstances we can optimize the execution just finding dependencies. You can observe that for calculate x we do not need any thing from previous execution, and the same for the y. With `alet` macro you can optimize this kind of cases: (defn do-foo [] (m/alet [x (do-first-thing) y (do-second-thing)] (+ x y))) In this code example the operations of x and y are executed in paralel. And this example uses promises, but we can use core.async channels, manifold deferreds, jdk8 computable futures, rxjs observables... And in future we can add a generalization macro that can look similar to this: (defn do-foo'' [] (m/async [x (m/await (do-first-thing)) y (m/await (do-second-thing)) z 2] (+ x y z)))) Also, using the same abstractions... This that, I intend to say that in clj/cljs we have the power to build more powerful abstractions that ES7 async/await. Regards. Andrey [1]: https://github.com/funcool/cats > > 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. > -- 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.
