6 ms·

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) sug

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
        I'm not saying that ClojureScript is for everybody. Obviously, different people like different things and that's why we have so many different languages available. However, the reason that async/await is difficult to do in ClojureScript as the main reason for leaving it is a strange one. It's clearly still very easy to do, even if ES7 version might be slightly cleaner at the cost of being baked into the core language semantics. When you compare all the things that are much uglier in JavaScript compared to ClojureScript, it's a bit of a silly argument to cherry pick async semantics in my opinion. I wouldn't expect ClojureScript to take over the world either. It's obviously never going to displace JavaScript, but it's reasonable to expect that it will continue to grow in popularity and that anybody who wants to work with it will be able to do so professionally.
- mad-mad-beaver 11y ago
  Oh, yeah, it replaces that cumbersome .then(() => doSome(thing)) with bare doSome(thing) and .catch(err => doOtherThing(err)) with catch (err) {doOtherThing(err)} A breakthrough indeed! I just don't see how's that fundamentally different and why one should have synchronous-like semantics for async operations. Moreover I do a lot of RxJS and like stuff and it's perfectly normal for me to have async computations steps wrapped in functions. Luckily no one tried to "improve" JS syntax specifically for RxJS. So I totally get async/await syntax and semantics but it forces me to switch mental context for no good reason and thus is useless and disconcerting. And it's ridiculous to see this minor "feature" as a reason to switch from CLJS to ES6/ES7
  - ilostmykeys 11y ago
    You seem oblivious to the advantage of organizing your async code in the same manner you organize your sync code. But the bigger reason I gave up on CLJS (besides core.async and its CSP model being a ridiculous over kill for simple async management yet being the primary choice the language gives you out of the box) was that ES6/7 are advancing at a much rapid pace than all of those Compile-to-JS languages and no one I know in the JS world would want to program a web app in a Lisp-like language (it's like using an RPN calculator rather than a normal one to do your taxes) for advantages that are disappearing fast relative to JS. The Extensible Web Manifesto embraces the Babel inspired iterate-before-you-approve spec development model and that just makes JS evolution go so much faster. So there is no hope for any niche language to unseat JS, and staying with a healthy and growing mainstream standard is far more appealing to me than writing web apps in Lisp-like language that once was a great choice (compared to ES5) but is no longer in that position. I hope ClojureScript continues to be a niche strong language but I'm really hapoy with the progress being made with JS as a language and ecosystem. Fatigue (what the article is about) is self inflicted IMO.

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
      I'm not saying that ClojureScript is for everybody. Obviously, different people like different things and that's why we have so many different languages available. However, the reason that async/await is difficult to do in ClojureScript as the main reason for leaving it is a strange one. It's clearly still very easy to do, even if ES7 version might be slightly cleaner at the cost of being baked into the core language semantics. When you compare all the things that are much uglier in JavaScript compared to ClojureScript, it's a bit of a silly argument to cherry pick async semantics in my opinion. I wouldn't expect ClojureScript to take over the world either. It's obviously never going to displace JavaScript, but it's reasonable to expect that it will continue to grow in popularity and that anybody who wants to work with it will be able to do so professionally.
mad-mad-beaver 11y ago
Oh, yeah, it replaces that cumbersome .then(() => doSome(thing)) with bare doSome(thing) and .catch(err => doOtherThing(err)) with catch (err) {doOtherThing(err)} A breakthrough indeed! I just don't see how's that fundamentally different and why one should have synchronous-like semantics for async operations. Moreover I do a lot of RxJS and like stuff and it's perfectly normal for me to have async computations steps wrapped in functions. Luckily no one tried to "improve" JS syntax specifically for RxJS. So I totally get async/await syntax and semantics but it forces me to switch mental context for no good reason and thus is useless and disconcerting. And it's ridiculous to see this minor "feature" as a reason to switch from CLJS to ES6/ES7
- ilostmykeys 11y ago
  You seem oblivious to the advantage of organizing your async code in the same manner you organize your sync code. But the bigger reason I gave up on CLJS (besides core.async and its CSP model being a ridiculous over kill for simple async management yet being the primary choice the language gives you out of the box) was that ES6/7 are advancing at a much rapid pace than all of those Compile-to-JS languages and no one I know in the JS world would want to program a web app in a Lisp-like language (it's like using an RPN calculator rather than a normal one to do your taxes) for advantages that are disappearing fast relative to JS. The Extensible Web Manifesto embraces the Babel inspired iterate-before-you-approve spec development model and that just makes JS evolution go so much faster. So there is no hope for any niche language to unseat JS, and staying with a healthy and growing mainstream standard is far more appealing to me than writing web apps in Lisp-like language that once was a great choice (compared to ES5) but is no longer in that position. I hope ClojureScript continues to be a niche strong language but I'm really hapoy with the progress being made with JS as a language and ecosystem. Fatigue (what the article is about) is self inflicted IMO.