Re:React/JavaScript fatigue
by ilostmykeys on Monday December 28, 2015 @06:55PM
(#10804234)
Oh right, that makes sense but does not make async code organize the way synchronous code does (as async/await sugar enables) but is a fair deal if you don't mind your async code using a different organizing pattern or if you specifically want it to be that way... :)
Re: cats
Not a big fan of abstractions that don't contribute to code simplicity. What is the percentage of programmer who dig monads? Less than 1% probably.
You're just cherry picking though. When it comes to complexity there's plenty more of it in Js than there's ever likely to be in ClojureScript.
Re:React/JavaScript fatigue
by ilostmykeys on Tuesday December 29, 2015 @05:01PM
(#10809369)
I am biased. Just as you are.
Objectively speaking, Js is a far more complex language than ClojureScript.
It's a trivial matter to wrap promise/all in a core.async channel, providing the exact orginzation pattern you're looking for.
Re:React/JavaScript fatigue
by ilostmykeys on Tuesday December 29, 2015 @05:01PM
(#10809367)
Show me the code! Go ahead and let's see how pretty that is, and son't forgeg error handling and concurrency.
I've provided all the code you need to put the pieces together quite trivially. Using go-catching, <? and the promise library (or just the core.async snippet I wrote earlier), you should be able to write the following:
(go-catching (<? (async-all [asyncOpA asyncOpB asyncOpC])))
And yes, that handles errors exactly like synchronous code does. The total number of lines for implementing go-catching, <? and async-all shouldn't take more than 20-30 loc, if not less.
Now, if 20-30 loc is too much for you to write, then by all means use JS.
Moreover, it has funcool/cats bindings, so you can use promises in mlet and alet macros if you are into monad thing ;)