Async/Generator functions in CLJS - (requesting feedback!)

Maybe I’m reading the post wrong, but what they say is they’ve improved the performance of Promises. And the charts actually even show that Promises are even faster then async/await.

I said “in the future”. Right now Promise code performs better. The coming improvements are mentioned later on in the post.

async / await outperforms hand-written promise code now . The key takeaway here is that we significantly reduced the overhead of async functions — not just in V8, but across all JavaScript engines, by patching the spec

1 Like

Interesting. I’m not sure what makes it faster then hand written Promises. Unless they mean non optimal hand written Promises.

The article @thheller posted in August explains one reason why. The gist of it is:

The fundamental difference between await and vanilla promises is that await X() suspends execution of the current function, while promise.then(X) continues execution of the current function after adding the X call to the callback chain. In the context of stack traces, this difference is pretty significant.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.

Do we still have chance to have async/await in ClojureScript?

Only @dnolen can answer that. His last answer was

basically I’ve already rejected this at least 2 times over after past 3 years

and I haven’t seen anything happen in the JavaScript world that makes me think it’s delivering enough value to take it on

and I doubt anyone will start work on it unless that has changed. It also would take quite a bit of work with lots of internal compiler changes so it might just not happen for that reason alone.

I’m still not sure it is a good idea either but given that the Browser support is now better for async/await then manual Promise code it might be time.

2 Likes

Although async/await is just syntax sugar over Promise, it has two advantages:

  1. emancipate programmers from chaining then or deep-nested callbacks.
  2. make async error handling easy. we can have a big try catch block at the beginning of our app, errors thrown from async/await functions will go up to the upper catch.

core.async solve first advantage as well, but I struggle to handle error in thrown in different functions.
After some search, I found async-error solve error handle issue with two macros go-try, <?. eg:


function fetchImg() {
  return Promise.reject("img");
}

function fetchCss() {
  return Promise.reject("css");
}

async function init()  {
  let img = await fetchImg();
  let css = await fetchCss();
  return img + css;
}

(async function() {
  try {
    let ret = await init();
    console.log("ok = " + ret);
  } catch (e) {
    console.log("e = " + e);
  }
}());

// e = img
(ns myapp.core
  (:require [async-error.core :refer-macros [go-try <?]]
            [cljs.core.async.interop :refer-macros [<p!]]))

(defn <fetch-img []
  (go-try
   (<p! (.reject js/Promise "img"))))

(defn <fetch-css []
  (go-try
   (<p! (.reject js/Promise "css"))))

(defn init []
  (go-try
    (try
      (let [img (<? (<fetch-img))
            css (<? (<fetch-css))]
        (println "ok = " (+ img css)))
      (catch js/Error e
        (println "err = " e)))))

(init)
err =  #error {:message Promise error, :data {:error :promise-error}, :cause img}