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?
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
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.
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
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).
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.
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
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.
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?).
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.
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.
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
