I am very disappointed by this as well. I am worried ReScript may have killed the momentum ReasonML had been gaining.

This is how I understand this:

  1996 - OCaml is born.
  2016 - ReasonML, an alternative syntax that compiles to OCaml, is launched by Facebook.
  2016 - A couple of months later, BuckleScript, an OCaml -> JS compiler is launched.
  201X - Collaboration happens, BuckleScript couples tightly to ReasonML.
  2020 - BuckleScript forks the ReasonML syntax and rebrands the compiler and the new syntax together under ReScript.
  2020 - ReasonML still exists?

Ok, fine. What is not clear to me is how the Facebook team behind ReasonML fits into ReScript. Are they aligned on the direction to take this community? What is the future of ReasonML?

What was the goal? If it was to ease adoption by newcomers, as a newcomer, it has made this more difficult. As someone VERY EAGER to enter this family of languages today, I ended up giving up on all of that and decided to just learn OCaml.

Now I'm dealing with Dune, Esy, OPAM, two competing async libraries and a community that is split between Jane Street libraries and the others.. but I really, really like OCaml!

> If it was to ease adoption by newcomers, as a newcomer, it has made this more difficult. As someone VERY EAGER to enter this family of languages today, I ended up giving up on all of that and decided to just learn OCaml.

This was my exact path. A friend and I wanted to make a small SaaS using Reason for the backend, because it smoothed out a bunch of what we considered were "rough edges" in OCaml. Then the ReScript split happened, and we realised that Reason was dead for all intents and purposes. It's hard to imagine the Reason team will continue updating Reason when they're focusing hard on ReScript instead.

here's the thing, _I don't think ReasonML is dead_! I've tried to dig for more clarity in the GitHub issue trackers and come up with mostly nothing. I am starting to get the feeling there is some kind of dispute or falling out between the maintainers of the two projects.

ReasonML isn't dead, but the way I heard the story it has always been a spare time project not a properly funded FB team. There was just enough spare time early on to get the community excited.

From the same source, I heard ReScript does have funding behind it.

Maybe they simply disagreed about the syntax...

Quite the opposite, Reason v4 looks to be taking inspiration from the changes ReScript has made.

For me, being an old dog, it is quite clear. Yet another guest language that fades away.

This feels a lot like what happened to Hack, which at first was compatible with PHP and could be compiled to it, but later became its own language to better fit FB's needs, and it seems like they're giving OCaml the same treatment here with ReScript.

There was actually some effort being made to keep OCaml tooling compatible with ReasonML (which is supported by dune[0] with no additional configuration) and BuckleScript integration with dune, which was being worked on before this rebrand, so it's kind of sad to see FB going off on their own with ReScript because they don't wanna do the work to upstream the changes they need.

By the way, regular OCaml also has its own JS backend[1] which is of course completely incompatible with BuckleScript.

0: https://dune.build/ 1: https://github.com/ocsigen/js_of_ocaml

> it's kind of sad to see FB going off on their own with ReScript

ReScript is not a Facebook project. The compiler is licensed by Bloomberg LLP: https://github.com/rescript-lang/rescript-compiler/blob/60a1...

And the syntax is licensed by the ReScript team: https://github.com/rescript-lang/syntax/blob/72d9b7034fc28f3...

The ReScript team is comprised of both Facebook and folks outside Facebook.

IMO this isn't about whether ReScript wants to upstream their changes, it's a combination of things:

- Reason+BuckleScript was confusing at best, having two websites and different release schedules.

- Reason's goal is to be a 100% mapped syntax for OCaml. This does not mesh well with the goal of producing readable JS, so ReScript will probably end up as a subset of OCaml features.

- Reason syntax changes apparently caused grief when applied to BuckleScript. This one was never very clear, but regardless now that the syntax is in-house the ReScript team can be more responsive with it.

The problem with this transition is that it was dropped on the community in an unfinished state and BuckleScript was retired completely. The goals of the change are, I think, mostly reasonable.

I have no skin in the game w.r.t to OCaml/Reason/etc. I do wish compile-to-JS languages would give up on the readable Javascript thing. I think ClojureScript nailed it with their reliance on Google Closure's aggressive optimization mode __because__ it produces obfuscated, highly optimized output.

Purescript also shares this goal, and it is a bummer, performance-wise, in older browsers that don't handle currying and various other "readable" representations well.

Worse still, if your target output is readable, then someone might start touching the compiled runtime objects with Javascript and then... god help you as you watch the guarantees of your fancy type system unravel before your very eyes.

"readable output" isn't really about being human-readable, except in unrealistic example cases. The bigger benefit is shared data types; this helps immensely with JS interop.

https://rescript-lang.org/docs/manual/latest/shared-data-typ...

I feel like the dev team is using "readable output" to mean both "human-readable" and "shared data types" depending on the situation. And it creates a lot of confusion.

Spyder81 is partly right, 'readable' doesn't mean 'human-readable' per se, it means rather that the compiler tries very hard to produce output JS that looks like idiomatic, hand-written JS. This means things like:

- Uncurrying functions

- Compiling OCaml modules to idiomatic JavaScript objects

- Compiling OCaml record values to idiomatic JavaScript objects

- Compiling tail recursion to idiomatic while loops

- And so on.

> someone might start touching the compiled runtime objects with Javascript and then... god help you as you watch the guarantees of your fancy type system unravel before your very eyes.

That's exactly what genType is for--it produces JavaScript, TypeScript, and Flow interfaces for ReScript output code so that people in the JS world can consume it transparently.

not sure if it's FB's decision or the project maintainer's.

I am rather disappointed and think F# 's Fable is a better alternative.

Sorry to say, it's not. F# is nowhere near the wonderful type-sytem of Ocaml(although it's intentional). I would stick with js_of_ocaml for my js needs.

last time I check, did not find a way to integrate jsoo easily with existing js code. is it any tutorial on how to write a js lib using jsoo?

You have to write binding glue code. Last i saw reason also required binding code to work.

Here is a react binding for jsoo: https://github.com/jchavarri/jsoo-react .

Feeling the same about this. Things were far clearer prior to this year -- I can no longer really see the point of the project and I'm just a bit sad about how it's all evolved. I've been following it since just before FB came in with ReasonML. I'd just started playing around with OCaml, found Bucklescript (which I still think is a marvel). Reason seemed like a way [albeit via that syntax] to get some traction for a very good language that imo seriously lacks in community, libraries and documentation. It felt slightly like Elixir, filling in a few holes in the underlying language and adding a layer of consistency. And it seeed a very good alternative to TS. But instead of coalescing into something, it seems to have just fragmented things further

I hope something good does coalesce, but it's currently very confusing. Maybe just me but the opportunity feels like it's slipping away. As say, been following things very closely so I fully appreciate some the issues & understand some hidden things are based on internal needs of that part of FB

I think the only cool project using ReasonML that is native is revery[0], which is being used for onivim[1].

[0]: https://github.com/revery-ui/revery [1]: https://onivim.io/

I'm rather confused: what is ReasonML ? is ReasonML now ReScript, or is it still its own thing? A quick google suggests ReasonML is for targeting native platforms? But I used it for the web at one point?

Anyway, there was already a problem with like three different standard libraries (which had super annoying differences like swapping parameter orders, presumably in an attempt to be friendlier etc.) or something when I first messed around with ReasonML (Bucklescript? Whatever the Facebook one was in 2019? I dunno.) and I hope this isn't also increasing that problem ?

ReasonML is merely an "alternate syntax" to OCaml, meaning it's a separate language that parses to the same AST. Traditionally it's been used along with Bucklescript, an OCaml-to-Javascript compiler developed by the same people, to do web work, but it's well-supported in the native OCaml compiler ecosystem as well.

Now that ReScript has superseded ReasonML+Bucklescript, the only niche remaining for non-legacy ReasonML is native development work by folks who just don't like the normal OCaml syntax, or want to target both runtimes with the same code.

Basically, the permutations are like this, with "ReScript (backend)" referring to the thing formerly known as BuckleScript:

OCaml/native: What normal people think of when they hear "OCaml".

ReasonML/native: Uncommon, but supported for folks who've bought into the Reason syntax.

ReScript (frontend)/native: Nobody does this since ReScript is strictly worse than ReasonML when targeting native. I don't even know if it's possible.

OCaml/ReScript (backend): Should be possible, but nobody does this.

ReasonML/ReScript (backend): Sort-of-deprecated in favor of the new syntax, but still supported, and most pre-existing projects are probably still using this.

ReScript (frontend)/ReScript (backend): Now collectively known as "ReScript" and the focus of the team going forward. New web projects are expected to use this.

AFAIK there isn't a ReScript to Native compiler. The way to do server-side ReScript is to use Node.

Thanks. That makes it very clear (to me), although definitely a harder sell to have to explain all these possibilities to others.

Paul Biggar of Darklang started a stdlibrary called tablecloth which offers the same API on frontend (Bucklescript/Reason) and backend (OCaml).

Yet he too gave up on ocaml

Yet another standard library for OCaml? You sure it wasn't a parody? :)

I can think of: TheActualStdlib, Base/Core_kernel/Core, Batteries, Containers, Belt, ...

It has different goals from them: https://github.com/darklang/tablecloth

Moreover it's hard to figure out which Ocaml version is Rescript on? Last i checked it was on 4.06, Do they backport any features, bugfixes?

Now it seems like it's a complete fork with a new syntax. Maybe it serves the interest of people at facebook, but Ocaml users are unlikely to be using this instead of js_of_ocaml.

well. rescript still compile pure ocaml code just fine.

Ocaml is a moving target, new features are added. Bucklescript was 4.02 for a long time before moving to 4.06. It is unclear what the current status of Rescript is.

It's still on 4.06, I think in 2021 they're targeting an upgrade (they haven't said how far forward they will upgrade to)