Is there a reason that rescript doesn't support `bs-let` or other 'async/await' type monadic suggars?

When writing code with lots of promises, rescript isn’t ergonomic at all.

I’m using the new promise bindings from @ryyppy , which are great with pipe first etc - but that doesn’t magically make code that is full of promises (that depend on each other) easy to read.

My use case, using rescript to test ethereum smart contracts - every single thing is a promise (a call to the blockchain). Firstly, this makes the code much more difficult to read.
Secondly, this poses a trade-off - either keep passing results of previous promises through the chain at each step and keep the promise chain flat, or nest the promises to keep values in scope. Neither of these creates very readable code, and both cause the code to have lots of noise (compared to javascript async/await).

Is there a plan to make rescript compatible with bs-let? Is there a plan down the road to introduce something like this in the language? Some clarity here would really help me - should I write those tests in reason syntax and wait until rescript supports this better, or should I rather try melange + latest reason syntax?

Thank you :pray:



Yeah, I think chaining async calls is less important for the client code, but otoh this could differentiate ReScript from SPA-specific (and therefore more batteries included) alternatives like Elm or the up-and-coming Mint.

Edit: of course, another thing that already differentiates it is the great mechanism for bindings. But again, custom bindings are probably more important when you cater to more use cases than just SPAs.

1 Like

Yes, that is probably true. Most people are using rescript with frameworks like react that don’t rely on promises much at all.

We have some really exciting progress, stay tuned!


Hi, do you have any updates on support bs-let?

Unfortunately not. You’ll need to stick with reasonml for code that does lots of promises in the mean time; that’s what I’m doing at least