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