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.
