Future of ReasonML, planned support for the BuckleScript/ReScript compiler

[gaku-sei]

Since the BuckleScript/ReScript rebranding we didn't get much information regarding ReasonML's future 😕

It seems a v4 is on its way (and from the look of it the new features are great!), but since there was no announcement of any sort I'm a bit confused, what will be included, and when it'll be released?

Also, does anyone know whether or not BuckleScript/ReScript will update the ReasonML version to v4 (as per some blog post, it seems they plan to keep "supporting" ReasonML, but are not explicit about how they'll support it)?

As a big fan of ReasonML and BuckleScript willing to keep using ReasonML instead of ReScript I'm really concerned about the lack of information and roadmap for ReasonML. Any news to share?

[ryyppy]

does anyone know whether or not BuckleScript/ReScript will update the ReasonML version to v4

ReScript's Reason version is feature frozen to v3.6 for backwards compatibility and will not get any further version updates within the compiler itself.

[tristanpemble]

forgive me, but I am still confused and am trying to read between the lines here. it's been a month 4 months since that announcement and I do not have confident answers to these questions:

• Will ReasonML still be actively developed?
• If ReasonML is continuing active development, will ReScript support any new developments to ReasonML?
• If ReScript does not support future changes to ReasonML, will the future ReasonML have a first-class browser target?

summarized as:

• If I want to enter this ecosystem and use one language to build to a native backend and a JavaScript frontend, what should I be doing now to prepare for the future?

[jordwalke]

@tristanpemble Thank you for the question and I apologize for the quiet period - I had taken a couple of months off of work.

ReasonML will continue development, and I'm working on some things that will make it easier for the community to assist in project management.

I'll provide the tentative plan (please be understanding if we need to adapt or reprioritize). Consider this as more of a sketch of ideas I think we should work on.

• Rewrite docs to make sense after the ReScript split (DONE)
• Rework documentation site. (In progress)
• Test and document all the native based editor workflows.
• Address remaining question in V4 feature set (Namely, what should string interpolation compile to?) Perform release.
• Various community organization - put out calls for projects that people may like to collaborate on for Reason project.
• Sponsor important/existing community projects.

There's a lot more that we need to do as well, but these are the ones I will for certain be working on immediately.
If anyone is interested in helping out please find me on Discord.

[TheSpyder]

• will the future ReasonML have a first-class browser target?

ReasonML has always had two ways to compile to a browser, but only one was advertised. This was probably done to avoid confusion but also for a lot of people BuckleScript was the better choice. That choice was removed during the rename to ReScript (except there is a backwards compatibility option for existing projects).

The other way is js_of_ocaml, it was created long before ReasonML and is well-used in the OCaml community so it will be around for a long time to come. For your use case it's actually the better option; code that leverages ReScript's advantages is unusable in a native backend, it was already like writing a different language, whereas js_of_ocaml aims to compile standard OCaml compiler output to the browser.

[tristanpemble]

thanks so much! so the way I am interpreting the conversations here and from the Hacker News comment section on the recent ReScript announcement:

• If you are focused entirely on a native workflow, ReasonML is still a safe investment and is still receiving development and community support.
• If browser or Node.JS interop is a priority, and you do not need to compile to native, ReScript is doubling down on your use case and is a safe investment.
• If you'd like to target both browser and native, you can use ReasonML + js_of_caml. This may be a less polished experience than with ReScript, and is an area that is still being explored, particularly with libraries like jsoo-react

[jordwalke]

@tristanpemble Sounds about right. If preserving your options for both js targets and native is important then Reason Syntax + jsoo is a potential option that is being explored and in fact we've put forth considerable effort into a prototype of what that could look like. It's also something we can invest much more in (sponsoring) if we have people willing to work on improving the jsoo compiler for this use case.

[TheSpyder]

Targeting both native and JS with Reason + JSOO has been a viable option for a while. I deployed it to production in 2017!

I developed the project as a BuckleScript app but deliberately kept the core agnostic so I could compile it to native and run the extensive tests really really fast. I ran into an issue with mutual recursion (hongbo refused to implement trampolining) and, because I only had a small layer of BuckleScript code, was able to port that to JSOO fairly quickly. It worked very well.

[Mathspy]

Has there been any surveys through the community of how everyone feels about ReScript? Since ReScript was not exactly a community effort via an open RFC and instead was an internal decision by some of the maintainers of BuckleScript it might be beneficial to see what's the perspective of the boarder community who targets JS via Reason/OCaml (the main target of ReScript, I guess?).

If enough people would rather keep using ReasonML itself and are uninterested in ReScript, it's possible as a community to champion that effort of maintaining BuckleScript the compiler via either forking it or maintaining a workaround similar to the only employed by reason-repacked. There are multiple reasons why BuckleScript has been a better compiler than JSOO, I mean it's based on JSOO with custom modifications that made it more developer friendly. So why don't we run such a survey over the community?

[TheSpyder]

Has there been any surveys through the community of how everyone feels about ReScript? Since ReScript was not exactly a community effort via an open RFC and instead was an internal decision by some of the maintainers of BuckleScript it might be beneficial to see what's the perspective of the boarder community who targets JS via Reason/OCaml (the main target of ReScript, I guess?).

Not specifically, but this is the wrong place to discuss it (as is discord). Take it to the official forum.

If enough people would rather keep using ReasonML itself and are uninterested in ReScript, it's possible as a community to champion that effort of maintaining BuckleScript the compiler via either forking it or maintaining a workaround similar to the only employed by reason-repacked. There are multiple reasons why BuckleScript has been a better compiler than JSOO, I mean it's based on JSOO with custom modifications that made it more developer friendly. So why don't we run such a survey over the community?

It's not based on JSOO, it's turned into a complete fork of OCaml that occasionally pulls in upstream changes. They take completely different approaches to the problem.

Reason-repacked is admirable but I wouldn't build a production system based on it. At some point (possibly many years from now) the option to use reason will be removed, and my plan is to work with the ReScript team to get the language to where I need it rather than fight and fork.

[Mathspy]

Not specifically, but this is the wrong place to discuss it (as is discord). Take it to the official forum.

I don't really know how useful it'd be to discuss a poll on whether or not people think ReScript is strictly an improvement over Reason in the ReScript forums which are under the control of the ReScript maintainers who already spent months of their time on the project

Reason-repacked is admirable but I wouldn't build a production system based on it. At some point (possibly many years from now) the option to use reason will be removed

I mean as things stand reason-repacked is just the latest version of Reason in ReScript but with the letop patch. I will be updating it to v4 whenever that's out though

my plan is to work with the ReScript team to get the language to where I need it rather than fight and fork.

I'd be on the same boat if for my lack of confidence in their intentions going forward. And technically speaking they forked and started "fight"ing changes (denying the letop PR and then closing it because they're "working on better alternatives" [none exists until today]) so I don't personally see the future being any different
I'd love to be proven wrong though. I'd love if they'd announce clear intentions or even start a survey of how people feel about the ReScript fork and whether or not they think improving Reason would have been a better option. Or even just show willingness to hear the community out on the features they want; instead of reinventing the wheel of async, we already have a primitive that does the job well and works today that's been avoided just because "it's too functional"

[jbhoot]

Will this new avatar of ReasonML be able to support react native? Currently it seems that ReScript dragged away the current react native support along with it.

[thelinuxlich]

I don't see a bright future for this project, one transpiled language was already enough on our plates to look for type definitions, now two...

[TheSpyder]

There won’t be two, because reasonml is no longer a transpiled language (the existing support for that is retained only for compatibility).

[thelinuxlich]

So what is the appeal of reasonml now?

[TheSpyder]

The same as it always was - an alternative syntax for OCaml. It's popularity as a transpiled JS language was always more thanks to the combination of it's good syntax with BuckleScript, and the BuckleScript team chose to create a new syntax breaking away from 100% OCaml compatibility (that among other things lead to the rename as ReScript). ReasonML maintains the 100% goal and that is incompatible with ReScript's new direction.

This change removes the appeal of ReasonML to JS users; eventually ReasonML will fade from the ReScript landscape and this awkward transition phase will be just a footnote in the changelog. But that doesn't mean ReasonML is dead.

It still has fans that compile to native OCaml (and it can still be used to generate JS via OCaml's standard js_of_ocaml). Onivim 2 is perhaps the most high-profile user of ReasonML as a targeting-native project.

[bernardro]

Hello,
First off, thank you for this project - I believe it can change the trajectory of Ocaml adoption

So.. Ocaml v5 is around the corner, tentatively two months from now (September 2022)
I have decided to dive into the Ocaml world
I would very much like to start off learning ReasonML syntax - but the release cadence and developer support (or popularity if you like) of ReasonML leaves me wondering

Leaving what the core issues with that are aside - can anyone suggest some clear cut reasons that would allow me to make a cut-throat yes or no decision as to whether to start off with Ocaml syntax (no) or invest in learning ReasonML (yes)

[nicosql]

Hello, First off, thank you for this project - I believe it can change the trajectory of Ocaml adoption

So.. Ocaml v5 is around the corner, tentatively two months from now (September 2022) I have decided to dive into the Ocaml world I would very much like to start off learning ReasonML syntax - but the release cadence and developer support (or popularity if you like) of ReasonML leaves me wondering

Leaving what the core issues with that are aside - can anyone suggest some clear cut reasons that would allow me to make a cut-throat yes or no decision as to whether to start off with Ocaml syntax (no) or invest in learning ReasonML (yes)

obvious choice is to learn OCAML, same as a budding web dev asking if they should learn Typescript or Javascript first.

Always learn the primitives in a transpilation, it's inescapable.

[anmonteiro]

Path forward is pretty clear now: Reason is OCaml, and can be used with Melange and Dune