Is async/await syntax important?

#1

Please feel free to comment with specifics.

  • Yes :+1:
  • No :-1:
  • Other :thinking:

0 voters

Show results
#2

May I ask, since async/await is only beneficial for JS-compiled Reason due to the built-in Promise, what about the Ocaml-compiled ones? I doubt there is an A+ implementation for that

#3

Let me clarify. There is a new OCaml syntax that can handle the async/await style of programming, called ‘let+ syntax’: http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html

This syntax can potentially be used with JavaScript promises in BuckleScript, and any other data structure which has the kinds of operations it supports. More details in the article.

Of course, that’s not to say that ReasonML would adopt that syntax as well, but I think at least there’s a good chance that it might happen.

#4

I think you misunderstood me. I am referring about the internals. Syntax is not a problem, what I am asking is how does Ocaml implement or support A+ ( I have never used Ocaml before, so I am curious about that)

#5

I think it is important to continue to attract the JavaScript community. Not sure about the native side, but I know that a natural and convenient async/await syntax would reduce resistance I encounter. Especially considering this advice from the V8 team:

And we also have some nice performance advice for JavaScript developers:

  • favor async functions and await over hand-written promise code, and

  • stick to the native promise implementation offered by the JavaScript engine
    to benefit from the shortcuts, i.e. avoiding two microticks for await.

– V8 Blog

#6

I’m not sure what you mean now :slight_smile: are you asking about ‘let+ syntax’? OCaml now supports that natively (in version 4.08 onwards), with no preprocessors needed. The mechanism from a user’s perspective is explained in the article I linked. From an implementation perspective, I don’t know the details, but if you’re interested here is the PR for the new syntax: https://github.com/ocaml/ocaml/pull/1947

#7

I am not referring to the syntax, I am referring to Promise itself (A+ is the Promise specification: https://promisesaplus.com/), which is why I need clarification on how does Ocaml support or implement A+ (Promise, in case you are confused).

#8

Oh, OK. I had never heard of A+. I had assumed that promises were added to JavaScript through the usual TC39 process.

Anyway, the short answer is that OCaml does not explicitly support A+, because A+ is a JavaScript platform-specific detail. BuckleScript supports JavaScript promises to the extent that it binds to them as part of its runtime library: https://bucklescript.github.io/bucklescript/api/Js.Promise.html . Note that it’s not re-implementing any of the behaviour that’s described in the A+ specification, it’s just binding to the existing standard promise implementation that ships with JavaScript platforms.

#9

so with this syntax proposal, you are only planning to target support for BuckleScript-compiled (JS) ReasonML?

#10

No, this (already-existing) syntax can support any platform as long as it is ported to it. It will essentially desugar into chains of .then(...) or similar calls depending on the exact platform and exact data type. Currently it exists natively on OCaml 4.08, and has been backported to earlier OCaml versions but only using the Dune build system. I’m saying that it’s a good candidate for including in Reason to get support for a wide range of use-cases, including async/await.

Edit: see the article I posted for details.

#11

Absolutely yes for web/JS as a target platform. In the conference, I got the feeling that because the vast majority of Reason devs work with React, and that because Promises are not important or necessary in React (I’m not a React dev, so apologies if I misunderstood), async/await therefore is not important/necessary as well.

No opinion for native.

#12

Promises are built-in for non-blocking processes for functions such as fetch. I don’t know how would they say “Promises are not necessary”.

#13

I haven’t kept up with the let+ syntax in OCaml, so don’t assume I know anything about the details here. :slight_smile:

Specifically on the topic of async/await syntax for JS promises, I’d prefer not having language-level sugar that is specific to an FFI feature (particularly one as flawed as JS promises).

If the syntax being proposed is more generic than that (e.g. similar to do-notation in Haskell), and it just happens to resemble async/await in JavaScript, and it can be made to work with JS Promises, I’m all for it.

#14

If anything, as a Reason/OCaml/FP newbie I’d like to hear more about what does the Reason team recommends instead of async/await, or, at least, what’s their considerations. IIRC, Cheng Lou mentioned they’re very cautious with async patterns in Reason and kind of waiting for the community to experiment with them some more.

(He also mentioned the React team had some issues with async data fetching, I wonder what those are.)

As a tangential, as someone planning to introduce Reason to a React/Redux project or two, I’m also curious about the Redux middleware story. I take it that Reason doesn’t support generators, so Redux-saga is out of the question, and, anyway, maybe something like Redux-cycles is a better functional approach?

#15

Hi hoichi, the official recommendation from the Reason team is here: https://reasonml.github.io/docs/en/faq#what-s-bucklescript-s-async-story

Part of the community experimentation around an async syntax sugar has been projects like Jared Forsyth’s let-anything which actually is pretty close to OCaml 4.08’s new ‘let+’ syntax. I think there is a question with these syntaxes of how to do error-handling in an elegant and idiomatic way (i.e. something that will compile down to myPromise.then(...).catch(...)).

Regarding the Redux middleware question, I recommend a new thread for that :slight_smile:

#16

Thank you! And you’re right about the new thread, of course.