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.

Reply via email to