4 ms·

promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things

promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS? More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code to know both? I'd recommend checking oit ESLisp on github, although they're still working on adding ES6/7 support. To each their own Dimitri :) i gave up on CLJS after it was evident to me that JS is maturing and has copied a lot of the stuff I like from CLJS plus some stuff from C# like async/await. Haskell is cool and so is Elm but all of these will ultimately be copied in pieces by the most dominant language on the web (JS) so it's easier to be on the receiving end of all that goodness as opposed to being stuck in any of those niche languages. Appologies. It's just my opinion.

mad-mad-beaver 11y ago
How is "never-ending-chain-of-thens" fundamentally different from async/await? It's still the very same code but with different (and somewhat disconcerting) sugar. I've been using promises long before ES7, and it's actually harder for me to read async/await functions and reason about them because they look so much like ordinary functions but aren't. There are useful features in ES6/ES7, to be sure: fat arrows, destructuring, imports/exports. Classes and spreads are useful too if you do a lot of React and JSX. But async/await, decorators and generators are just fancy and questionable ways to perform routine functional stuff one can easily do in shaggy pre-ES5 Javascript. I write a lot of ES6/ES7/JSX at work and CLJS at home and 100% prefer the latter. I want immutable values with destructuring, lazy sequences, suit of threading macros, decent cond|p/case, protocols and whole CLJS ecosystem. I've adapted to ES6/ES7/Redux/RxJS and often even could write code near-identical to CLJS/Reagent/Re-frame/Reagi stack. But it is definitely more painful and limiting experience.
- ilostmykeys 11y ago
  Async/await doesnt lead to a long chain of thens with a trailing catch. It gives you proper synchronous semantics like any other synchronous code, while allowing you to specify concurrent logic. Its syntax is very understanable. You're missing out! I think you don't actually have a clear idea if you think async/await is a step backwards. You're arguing for the sake of arguin, right? Else, give me some examples in code. Thanks.
  - yogthos 11y ago
    Perhaps you could instead provide an example of a concrete problem that you believe to be difficult to tackle with CLJS.
  - ilostmykeys 11y ago
    @yogthos Nothing is hard to do in CLJS but finding the right way to do things can be hard. For example, why doesn't core.async include promises and even better some async/await equivalent? Why does core.async push CSP as the built in async model to the exclusion of all other async patterns? Why are those only found in some 3rd party libraries?
    - yogthos 11y ago
      >Nothing is hard to do in CLJS but finding the right way to do things can be hard. So you're saying that you have to learn the language and its ecosystem. Please explain how that's different from any other language. >For example, why doesn't core.async include promises and even better some async/await equivalent? Because it has different design goals. >Why are those only found in some 3rd party libraries? Because most people find the core.async approach to work well. However, since such libraries exist and have great documentation, I fail to see the problem. In fact, not baking things into the language itself is one of the greatest benefits of Clojure. The language itself is minimal and makes very few assumptions. This means that it can be extended through libraries to many kinds of domains. The more assumptions the core language makes the more rigid it becomes.
      - ilostmykeys 11y ago
        The thing is many people try ClojureScript and end up leaving while many others do stay. I am in the former group and my reasons are exactly what i stated but you are right to point out that my reasons may not be everyone's reasons, which I never assumed. Hence the Rant tag. Fair enough, some people find use of CSP for simple scenario of concurrent wait-for-all async management a natural fit but i find it an overkill. Promises are fine but I find async/await syntax much more easy to understand. I do hope CLJS stays a strong niche language but any hope of it taking over the world is unlikely, IMO.
yogthos 11y ago
>promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS? There's a long discussion here, which I'm pretty sure you're already aware of, on the tradeoffs: https://groups.google.com/forum/#!topic/clojurescript/LBy0yiZiWrA https://groups.google.com/forum/#!topic/clojurescript/LBy0yi... Each approach has its downsides, but clearly core.async and promises work just fine here. >More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code to know both? Language semantics is why. ClojureScript has much cleaner semantics than Js and languages that provide syntax sugar on top of it. It's immutable by default, has clean and consistent syntax, and far less gotchas than Js. Nobody actually mixes Js with ClojureScript. People write libraries backed by Js internally, but the users of these libraries don't have to know or care about that. The real question is why would somebody want to learn the giant clusterfuck that ES6/7 constitutes when far saner alternatives are available. > i gave up on CLJS after it was evident to me that JS is maturing and has copied a lot of the stuff I like from CLJS plus some stuff from C# like async/await. Adding features to an already poorly designed language does not make it better. You end up with a giant kitchen sink language that takes inordinate brainpower to work with. We've already seen that this is a bad idea with languages like C++ and Scala. And no, you can't just learn a snae subset of the language, because sooner or later you have to deal with code written by other people. If working with a giant quirky mess that looks like this https://i.imgur.com/AjSTP20.png https://i.imgur.com/AjSTP20.png is you cup of tea then who am I to stop you, but I certainly question that it's a rational choice. :)

mad-mad-beaver 11y ago

How is "never-ending-chain-of-thens" fundamentally different from async/await? It's still the very same code but with different (and somewhat disconcerting) sugar. I've been using promises long before ES7, and it's actually harder for me to read async/await functions and reason about them because they look so much like ordinary functions but aren't. There are useful features in ES6/ES7, to be sure: fat arrows, destructuring, imports/exports. Classes and spreads are useful too if you do a lot of React and JSX. But async/await, decorators and generators are just fancy and questionable ways to perform routine functional stuff one can easily do in shaggy pre-ES5 Javascript. I write a lot of ES6/ES7/JSX at work and CLJS at home and 100% prefer the latter. I want immutable values with destructuring, lazy sequences, suit of threading macros, decent cond|p/case, protocols and whole CLJS ecosystem. I've adapted to ES6/ES7/Redux/RxJS and often even could write code near-identical to CLJS/Reagent/Re-frame/Reagi stack. But it is definitely more painful and limiting experience.

ilostmykeys 11y ago
Async/await doesnt lead to a long chain of thens with a trailing catch. It gives you proper synchronous semantics like any other synchronous code, while allowing you to specify concurrent logic. Its syntax is very understanable. You're missing out! I think you don't actually have a clear idea if you think async/await is a step backwards. You're arguing for the sake of arguin, right? Else, give me some examples in code. Thanks.
- yogthos 11y ago
  Perhaps you could instead provide an example of a concrete problem that you believe to be difficult to tackle with CLJS.
- ilostmykeys 11y ago
  @yogthos Nothing is hard to do in CLJS but finding the right way to do things can be hard. For example, why doesn't core.async include promises and even better some async/await equivalent? Why does core.async push CSP as the built in async model to the exclusion of all other async patterns? Why are those only found in some 3rd party libraries?
  - yogthos 11y ago
    >Nothing is hard to do in CLJS but finding the right way to do things can be hard. So you're saying that you have to learn the language and its ecosystem. Please explain how that's different from any other language. >For example, why doesn't core.async include promises and even better some async/await equivalent? Because it has different design goals. >Why are those only found in some 3rd party libraries? Because most people find the core.async approach to work well. However, since such libraries exist and have great documentation, I fail to see the problem. In fact, not baking things into the language itself is one of the greatest benefits of Clojure. The language itself is minimal and makes very few assumptions. This means that it can be extended through libraries to many kinds of domains. The more assumptions the core language makes the more rigid it becomes.
    - ilostmykeys 11y ago
      The thing is many people try ClojureScript and end up leaving while many others do stay. I am in the former group and my reasons are exactly what i stated but you are right to point out that my reasons may not be everyone's reasons, which I never assumed. Hence the Rant tag. Fair enough, some people find use of CSP for simple scenario of concurrent wait-for-all async management a natural fit but i find it an overkill. Promises are fine but I find async/await syntax much more easy to understand. I do hope CLJS stays a strong niche language but any hope of it taking over the world is unlikely, IMO.

yogthos 11y ago

>promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS? There's a long discussion here, which I'm pretty sure you're already aware of, on the tradeoffs: https://groups.google.com/forum/#!topic/clojurescript/LBy0yiZiWrA https://groups.google.com/forum/#!topic/clojurescript/LBy0yi... Each approach has its downsides, but clearly core.async and promises work just fine here. >More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code to know both? Language semantics is why. ClojureScript has much cleaner semantics than Js and languages that provide syntax sugar on top of it. It's immutable by default, has clean and consistent syntax, and far less gotchas than Js. Nobody actually mixes Js with ClojureScript. People write libraries backed by Js internally, but the users of these libraries don't have to know or care about that. The real question is why would somebody want to learn the giant clusterfuck that ES6/7 constitutes when far saner alternatives are available. > i gave up on CLJS after it was evident to me that JS is maturing and has copied a lot of the stuff I like from CLJS plus some stuff from C# like async/await. Adding features to an already poorly designed language does not make it better. You end up with a giant kitchen sink language that takes inordinate brainpower to work with. We've already seen that this is a bad idea with languages like C++ and Scala. And no, you can't just learn a snae subset of the language, because sooner or later you have to deal with code written by other people. If working with a giant quirky mess that looks like this https://i.imgur.com/AjSTP20.png https://i.imgur.com/AjSTP20.png is you cup of tea then who am I to stop you, but I certainly question that it's a rational choice. :)