ReScript Frequently Asked Questions

5

Hi, thanks for asking, there are lots of questions, so we may edit and refine later.

Is there an overview of the (current and/or expected) concrete differences between ReScript and ReasonML

This is not an apple to apple comparison, ReasonML is a parser, it is not a language on its own, it is hooked to ReScript compiler as an input. ReScript support multiple syntaxes, it recently introduced its own syntax which is similar to ReasonML but different to favor JS experience. For example, in the new ReScript, [1,2] is exactly js array [1,2] while in ReasonML notation, [1,2] is a list {hd : 1, tl : { hd : 2, tl: 0}}, this could cause confusion to JS users.

Tech aside, the other important part is that ReasonML parser has different goals which don’t fit our vision, for example, it aims to support all OCaml versions which makes it quite large and we can not embed it inside our compiler (we have to spawn an external process just for parsing).

How does ReasonReact relate to ReScript and ReasonML?

ReasonReact is part of the ReScript ecosystem. There’s no compete between ReScript and ReasonML since they are not apple to apple comparison as I said before, the ReasonML is one component in the ReScript compiler that we want to replace it with a dedicated JS like syntax.

Differences with TypeScript

TypeScript is an awesome language. The difference is the trade off we made between TypeScript and ReScript. TypeScript is designed to be a JavaScript super linter, it uses type system to give your better editing experience, it has seamless interop with JavaScript, at the same time, it inherits all JavaScript gotchas. While ReScript is a clean slate, the compiler is built in native code, which is much faster (10x not 10%), it has a sound type system and optimizing compiler which generates optiimzed code based on type information, at the same time, it tries to make JS interop as seamless as possible.

So you can think that TypeScript and ReScript are solving the JS typing in two directions, TypeScript takes what JavaScript gives and try to make it more strongly typed while ReScript take a clean slate and try to make it more JavaScript friendly.

We currently use TypeScript on the back end, too. Does ReScript fit the purpose?

Yes, we support backend on Node

The other questions are answered by other people, I will do some cleaning later and add it back to the FAQ

5 Likes
6

Thank you, this is very enlightening.

How is the stance of ReScript towards upgrades in OCaml? I’m not closely following its evolution. But assuming improvements in the type system can be made (if I had to think of a fictional example: making the type system aware of array length, even if only under some conditions, obviating certain null checks in code, in case of uncertainty defaulting to failing the build), would such improvements easily get incorporated into ReScript?

Apologies if far-fetched
Thanks in advance

7

How is the stance of ReScript towards upgrades in OCaml?

We will do upgrade once roughly every two years. OCaml is a very stable language, the type system does not change that much in the last ten years. Also, we do some cherry-picks sometimes to get enhancement from upstream

4 Likes
8

Very welcome thread! Thanks for making a place for centralized Q&A.

Another question:

Is the ReScript team funded by some company, or an individual effort by the team members?

If you were to start a project today with it, would you write your files in .re or .res syntax? There is a learning curve for both coming from JS, and the docs on the new site are in .res syntax.

2 Likes
9

Is the ReScript team funded by some company, or an individual effort by the team members?

Some of us are working on it full time, some donate their free time. For example, I work on the compiler full time funded by Facebook, the new syntax is mostly done by Maxime on his free time.

If you were to start a project today with it, would you write your files in .re or .res syntax? There is a learning curve for both coming from JS, and the docs on the new site are in .res syntax.

This is case by case. If you have a high demand on IDE, you may start with reason syntax (you’ll wait a couple of months for the editor integration to be released to migrate to res syntax later, we will provide tools so that you can migrate in one click), the reason docs are hosted in reasonml.org and reasonml.github.io

4 Likes
10

Are there plans to introduce a best practice for naming NPM packages? I’ve just updated one of my packages and thought about what the name should be once I switch to the ReScript syntax.

I came to the logical conclusion of res-package-name, but I’m curious if there is something planned (maybe a binding registry after all that requires a certain naming pattern).

6 Likes
11
  • Why create a new syntax?
    The existing Reason syntax is owned by a different team with a different vision.

As I understood the developers mentioned (Bob, Cheng, Cristiano, Maxim, Patrick, Ricky) were part of the Reason team.

I thought ReScript was supposed to be a combination of BuckleScript and Reason. So I’m slightly confused as to the relationships here.

It sounds like there is now some competition / tension between ReScript and Reason which is concerning.

12

As I understood the developers mentioned (Bob, Cheng, Cristiano, Maxim, Patrick, Ricky) were part of the Reason team.

Previously, to make people less confused about the relationship between OCaml, BuckleScript and ReasonML, everything is called Reason, but they are doing different parts of the work.

It sounds like there is now some competition / tension between ReScript and Reason which is concerning.

Hi, there’s no competition between ReScript and Reason, reason is a syntax which is not a product on its own, it needs be hooked to ReScript compiler to do the job. ReScript will support Reason syntax for a very long time and will provide a migration path to ReScript’s own syntax for people who want to do the conversion.

3 Likes
13

Ok, great. Thank you for the explanation.

14

Will the community see some convenient way of working with Promises like async/await in the near future?

1 Like
15

In the short term, I think we can simplify the promise binding a little bit.
for example, instead of promise <'value, 'error>, we make it promise <'value>, the 'error will always be of type exn

16

If you are going to make breaking changes to the Promise bindings, then please also make them pipe-first.

5 Likes
17

I switched to Anton’s promise library a while ago and haven’t looked back. It does enforce boxed promises normally, but for working with libraries that return promises I have found his Promise.Js module is a lot easier to use than the built-in Js.Promise. I can go into detail later, rather than derail this thread.

3 Likes
18

Wouldn’t that make them less typesafe? (Especially when using library code, you basically have to coerce the errors to the right type with is error prone?).

19

it will be type safe, the conversion is done mandatory

20

Of course, but you the conversion is error prone (because the error isn’t typed anymore). We had a lot of these cases in graphql-ppx where you had to coerce a generic type (Js.Json.t) to an explicit type, and it was the source of a lot of bugs.

21

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
22

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:

23
24

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

5 Likes