ReScript Frequently Asked Questions

I can imagine that when you get a promise from the Apollo GraphQL client it is very nice to have type-safety of the error response because it’s a very explicit shape. If people have to cast it explicitly in this shape it’s both error prone and harder to use.

2 Likes

Yeah, I think this might be a useful discussion. Like what are the promise-related usecases and patterns, and when something Result-compatible like aantron/promise or reason-future makes more sense. Even if ReScript doesn’t adopt this approach, it might be useful for the community :slight_smile:

Maybe time to split this out into a new thread for ReScript Promise Redesign or something like that.

5 Likes

It seems that all examples on the new docs site are in ReScript. Does it mean there will be no vanilla OCaml sample code any more?

We’ll provide a command line to convert between Rescript syntax and OCaml syntax and vice versa.
About the documentation site cc @ryyppy

The old vanilla ocaml syntax now sits alongside the old reason syntax, in the doc version 8.0.0: https://forum.rescript-lang.org/t/the-documentation-is-now-versioned-old-syntaxes-added-reasonreact-docs-redirected

2 Likes

Hi, I have a few minor questions.

1. Any chance switch will be renamed to match?

This might be quite a silly question, but my reason for asking is that the switch-keyword kinda reminds me of the handicapped switch in Javascript and what I currently really miss.

2. Some of the API’s seem to use snakecase, will these be changed to camelcase?

My reason for asking is that it feels a bit inconsistent, in my amateur opinion.

3. Are the terms Belt/Bucklescript/BS going to stick around, or will these be renamed in the future to something more rescript-like?

4. The @-operator was usable for concatenating lists, I can’t seem to use it anymore. Is this on purpose?

5. Will it be possible to spread syntax on arrays in the future?

6. Are there any plans to target WASM with rescript?

Thank you for your time.

Hi @doctorgoat!

1. Any chance switch will be renamed to match?

No. switch is the final syntax for pattern matching expressions

2. Some of the API’s seem to use snakecase, will these be changed to camelcase?

There are some functions that are still using snake_case due to the origins of some compiler builtins. Most of them come from the Pervasives module, or can also be found in the List and Array modules. The convention is to use camelCase for all new APIs (like in the Belt.Array or Js.List etc).

3. Are the terms Belt/Bucklescript/BS going to stick around, or will these be renamed in the future to something more rescript-like?

BuckleScript was the original name before it was rebranded to ReScript and is therefore obsolete. All occurrences of BS / BuckleScript etc. will slowly be replaced with the new ReScript naming equivalents in the future.

Belt (as a name) is probably going to stay, since it’s still an okayish name for a stdlib module, and we can’t really deprecate it for backwards compatibility reasons.

4. The @-operator was usable for concatenating lists, I can’t seem to use it anymore. Is this on purpose?

The @ operator is an infix operator, which is currently not supported by the ReScript syntax. There are discussions on how far those will be actually supported, since we believe that infix operators encourage too many different library driven DSLs that cause problems in readability etc.

5. Will it be possible to spread syntax on arrays in the future?

No discussions on this yet.

6. Are there any plans to target WASM with rescript?

There are no plans for WASM support. Our goal is to compile to readable, performant and easy to integrate JS code.


Hope this helps!

3 Likes