What is the chance that CLJS will ever have bespoke syntax around async/await: higher or equal to zero? I'm not advocating for it or against it, I just want to know the (current) likelihood.

@borkdude The <p! macro has been a near drop-in replacement for await for me. Are you looking for something different?

I'm not looking for anything. I just want to know exactly what I'm asking. Not looking for solutions :-).

Ah, OK. 🙂

@borkdude I don't see how this wouldn't be some kind of syntactical change - so the likelihood is pretty low - I haven't encountered a single situation it is necessary - nor have heard as of yet convincing arguments otherwise

not enough to introduce new syntax

also semantic change seems to me - since it would necessarily generate functions w/o Clojure semantics

if something like this existed it probably would not be allowed to interact w/ fn syntax - at which point - why bother?

from an implementation perspective, would it be far more complex than generating the words await and async at the right spots and let JS deal with the complexity?

And Closure can handle it as well

But that's the thing - if you really need this stuff, I just don't see how it isn't solved by writing some JavaScript - we made that relatively easy long ago

Could you please clarify what do you mean "by writing some JavaScript". Do you mean using *js in cljs or literally write Javascript?

Literally write JavaScript and import it, compile using the bundle target.

I suspect more like this:

import { readFile } from 'fs'
const foo = await Promise.resolve(100);

export default foo
---
(ns foo
  (:require ["./foo.mjs" :refer [default] :rename {default foo}]))

(.log js/console foo)

that type of require is shadow-cljs only 😉

async/await is one of the biggest wins for the JS ecosystem since it makes code more readable compared to promises/callbacks. I know we can use channels. I am aware of their existence and use them regularly. However, there are types of applications e.g. puppeteer tests, AsyncLocalStorage + fibers that require the usage of pure Promises. Using channels the user might shoot itself in the foot quickly. I am aware that async/await for Clojurescript on the browser has a little sense, but for Node.js is essential.

Have you looked at https://funcool.github.io/promesa/latest/user-guide.html?

Here is a puppeteer test with promesa. https://github.com/borkdude/nbb/blob/main/examples/puppeteer/example.cljs Promesa is just a bunch of short macros that translate in chained promises. I like it.

One could argue that because macros aren't a thing you need a committee to add things to a language like JS

I'm aware of other alternatives, but thanks anyway 😄

I used Puppeteer w/ core.async 3 years ago - it just works and works great, I still have my feet 🙂

anyways - it ain't gonna happen until somebody comes with an incredible reason that hasn't been considered yet

re: just writing JavaScript ...

you can write modern JavaScript and Closure can process it along w/ your ClojureScript

you can write modern JavaScript in files w/ goog.provide

again some of these things were validated by transit-js even more years ago

IMO absolutely nothing of interest has happened as far as ClojureScript is concerned to JavaScript since 2001 - which is more or less the version of JS we generate

@dnolen yep. I was just wondering, I'm not particularly interested in adding stuff to the language myself, but for #nbb I would like to be compatible. If I were to introduce some kind of mode for the REPL where it would await top level expressions, I wanted to make sure I didn't miss anything going in in CLJS.

yeah no plans

the only proposed features for JS that I've felt anything enthusiasm for - real 64 bit ints, and fast multimethod arithmetic to make it work

https://webkit.org/blog/7846/concurrent-javascript-it-can-work/

I think there are things we win by generating async/await: potentially better efficiency and error handling, and avoiding the core.async macro pains if we know we're working with just promises. is that worth the cost to developing it into the language? sounds like that's been answered. but there are second-order wins, to me

we've hashed this all out before, IIRC the biggest impediment is that we use a lot of IIFEs to handle do and similar expressions and those conflict with async needing to be at the function boundary

so it's not a matter of "just emit async / await" and be done, since it would break strangely when used with let or any number of expressions that implicitly wrap the body in a function in order to return as an expression. and that problem would have to be solved before letting it into the language. then as dnolen alluded to there's the problem of syntax and breaking from Clojure more

yep, expression oriented language and access to async await primitive just isn't going to work

I was alluding to that above in the adding such a constructs is just creating a lot of trouble and absolutely minimal value

at some point this might just be fixed for us in the language if certain proposals get accepted, i.e. do-notation

but those are such pie-in-the-sky proposals IMO

and there always ends up being some weirdness that makes it awkward. design-by-committee has its shortfalls....

Fortunately JS optimizers came before all this stuff