Feel free to ask questions. We’ll add the answers here and back to https://rescript-lang.org/docs/manual/latest/faq
14 Likes
Thank you very much for putting your energy into this project. I genuinely believe that this is the direction of the future, and hope ReScript can succeed as (one of) the main language(s) in which to develop JavaScript code.
I’ve been following the project for a couple of years, and ever since been on the fence whether to adopt in our web app.
Thinking about what has hindered my adoption, the obvious answer is our lack of discretionary resources. But that is only part of the story, given that every development effort is a trade-off, and if the argument of a long-term net positive can be made, something else must be hindering our adoption of ReScript.
That something else is TypeScript. Due to happenstance, I came into contact with it earlier, and we’ve recently more-or-less completed an entire codebase transition to TypeScript. More-or-less, because we can’t yet enable the “strict” flag due to non-null errors.
Looking at the popularity of this other language, I guess there are many people in a similar situation. Instinctively, however, and due to reasons well outlined elsewhere, I seem to strongly prefer ReScript over TypeScript.
In our case, I decided to first do the conversion to stricter (more correct) types, and then consider a further migration to ReScript. This, however, has until now been based on gut feeling. I think the documentation can benefit strongly from explaining the following:
- Differences with TypeScript and Flow (I don’t think would set the wrong tone, as long as it’s a balanced comparison)
- Adoption strategy for TypeScript codebases. Are there common pitfalls? Do common patterns exist in the migration strategy?
- We currently use TypeScript on the back end, too. Does ReScript fit the purpose? I understand that it’s just generated JS. But does ReScript come with its own package repository (same as ReasonML) or does there exist a typings repository on NPM similar to
@typesandflow-typed? This seems like the least mental overhead, although initially quite incomplete. - In the case of a TypeScript codebase like ours, would you recommend to complete the current types first, or to immediately migrate to ReScript? Put differently, will refactoring TS code to more strict types typically ease the transition to ReScript, or is the expected effect negligible? As it stands now, the benefit from migrating to ReScript from a strictly typed TS codebase seem more difficult to defend.
- If someone who uses TypeScript has the self discipline (and/or tooling) to completely avoid
any, does TS still allow for type errors that ReScript eliminates? In my current understanding, it doesn’t, but I haven’t seen this point addressed anywhere.
I hope this is the right place to ask these questions; if not, I’ll gladly post them elsewhere. But I think these questions are relevant to many new people getting to know this project.
- I would also be curious about the current adoption status and future adoption expectations at Facebook. Last anecdote I read was that messenger.com was written in ReasonML. The relation between ReScript and Flow might be of interest to Flow users as well.
- How does ReasonReact relate to ReScript and ReasonML?
- Is there an overview of the (current and/or expected) concrete differences between ReScript and ReasonML? Perhaps it’s described here: https://reasonml.org/docs/reason-compiler/latest/new-bucklescript-syntax? Am I correct in assuming that the “old” vs. “new” syntax in this article are the ReasonML and ReScript syntaxes?
- Lastly, it would be nice to have a (feature/tooling/…) roadmap!
I’m glad to see the blog being more active, and have good hopes for the future. Good luck!
4 Likes
If someone who uses TypeScript has the self discipline (and/or tooling) to completely avoid
any, does TS still allow for type errors that ReScript eliminates?
Just to answer this question, Typescript is an avowedly “unsound” type system, as they explain in their docs:
Ocaml, however, has a sound type system, and therefore so does ReScript. One simple example of why this can save you from bugs in ReScript but not in Typescript is array access.
In Typescript, x is of type number, even if array is empty:
const [x] = array
But in ReScript, array access always returns an option, so you always have to handle the case where an array might be empty.
5 Likes
About migrating from TS: There was recently a talk about that at the last Reason Stockholm meetup.
I think the “leafs-first” approach makes sense and lets you gradually introduce smaller ReScript components into a TS codebase.
You basically start by rewriting some (small) TS component in ReScript, and then let genType automatically generate TS types for you, which can be consumed from the parent component(s) which are still in TS.
There is no need to convert to stricter TS in between, that would be a waste of time IMHO.
2 Likes
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
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
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
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
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
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
- 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.
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
Ok, great. Thank you for the explanation.
Will the community see some convenient way of working with Promises like async/await in the near future?
1 Like
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
If you are going to make breaking changes to the Promise bindings, then please also make them pipe-first.
5 Likes
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
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?).
it will be type safe, the conversion is done mandatory
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.