[ANN] Timeline to retire reason syntax support

Dear Rescript users,

If you do not use ReasonML syntax, feel free to ignore this post.

Maintaining a language and toolchain takes a lot of time. Up to now, the maintenance of Rescript toolchain is entirely up to volunteer work so that we only have limited resources. The ReasonML syntax support was deprecated more than one year ago, we would like to continue support it (unless something unexpected happen) in the next major version and remove it afterwards.

We hope this could make you enough time for the transition from ReasonML syntax to Rescript syntax.

Feel free to leave your feedback here or PM if you have some concerns.

Best – Hongbo

12 Likes

Hey @Hongbo, Thanks for the clarification.

Seems like maintaining the Reason syntax takes a lot of time, and it’s the main decider to remove it. Is that accurate?

and what about the OCaml syntax?

Thanks

The reason syntax is not well maintained long before the deprecation, its code size keeps getting bloated while not too many bug fixes. It does not share the same philosophy we have in developing rescript toolchain, where “quality” is valued significantly.

The rescript syntax still needs some improvement but now we own it so we will spend some time improving its experience.

what about the OCaml syntax

We don’t want to break the user code for no good reasons, in the forseeable feature, I dont see a motivation to remove it but it won’t receive first class support as rescript syntax.

1 Like

Keeping ocaml support is nice for shared code like type definitions shared between native ocaml and rescript for example. But given the current state of ReasonML, it makes sense to deprecate it to focus on more interesting topics I guess.

1 Like

I’m about to start migrating the big project I work on to ReScript syntax. We need to start training new developers on it and I don’t see any point in teaching them reasonml now.

I also noticed the M1 build of v10 doesn’t work with reason syntax (the bsrefmt binary isn’t linked into the arm64 folder, although adding it manually works thanks to Rosetta). So it seems like a good excuse to start the transition.

In my initial experiments I’ve already found a bug in the converter/formatter - I’ll log it on GitHub when I can come up with a simple replication case.

[edit] done: https://github.com/rescript-lang/rescript-compiler/issues/5316

1 Like

What are the most widely used reasonml libraries right now and what is the transition plan for each of those libraries?

I’ve been slowly working on forks of libraries that I use; most haven’t been updated in so long that I assume the authors moved on after the split. They still work very well but many were created before modern ReScript techniques like records-as-objects so I’m taking the opportunity to make API updates in the hopes they will be more approachable.

  • bs-webapi has become rescript-webapi, and I’m working on merging bs-fetch into it.
  • I’ve taken reason-nodejs and created rescript-nodejs.
  • I’m planning to do a conversion of bs-mocha soon, if nobody else does.
4 Likes

Thanks for raising the conern. That’s why we still support ReasonML in the next major release (for a year) so that stake holders can pick up and move forward

I wasn’t really raising an abstract question. I concretely think we should start listing the abandoned libraries now and start putting out call for maintainers.

most haven’t been updated in so long that I assume the authors moved on after the split.

This, exactly.

1 Like