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.
