3 ms·

> ReScript is not just a rebranding: it’s a ReasonML which freed itself of the yoke of the OCaml ecosystem. By doing so, it forfeited compilation to native code

> ReScript is not just a rebranding: it’s a ReasonML which freed itself of the yoke of the OCaml ecosystem. By doing so, it forfeited compilation to native code and OCaml library interop, but gained a freer syntax which further resembles JavaScript See also BuckleScript & Reason are now called ReScript: https://rescript-lang.org/bucklescript-rebranding https://rescript-lang.org/bucklescript-rebranding

frou_dh 6y ago
Here's a great comment explaining all the permutations: https://news.ycombinator.com/item?id=25426438 https://news.ycombinator.com/item?id=25426438 At least from a branding perspective, it seems the whole thing has been quite bungled. But obviously what's more relevant is how well the technical goals actually get met.
- globuous 6y ago
  Generally speaking, I am pretty happy with the (small) syntax changes from Reason to Rescript [1]. No necessary semi-colon, arrays, object declaration & access. We can finally pattern match on arrays [2] which I think was not possible with Reason (only lists were). However, there are no custom infix operator with Rescript [1], which is quite sad as it makes monadic code cleaner, whereas they were supported by ReasonML. [1] https://rescript-lang.org/docs/manual/latest/migrate-from-bucklescript-reason https://rescript-lang.org/docs/manual/latest/migrate-from-bu... [2] https://rescript-lang.org/docs/manual/latest/pattern-matching-destructuring#match-on-array https://rescript-lang.org/docs/manual/latest/pattern-matchin...
- richeyryan 6y ago
  A couple of years ago I was a big advocate of ReasonML and went so far as to run a meet up. I honestly believed in the technical value of it and saw it as a better alternative to Typescript. At the time, the waters were muddy enough with Reason, Bucklescript and OCaml but you could explain it away. The rebrand and change of syntax that came with Rescript was the end of the line for me. Issues like async await have gone unaddressed for years and instead the community is caught up on syntaxes and compilation targets. I turned to Clojurescript since. It solved most of it's problems years ago and its functional enough that I don't miss the static types. The large standard library also avoids the questions around whether you should use Belt or Tablecloth or any of the other "standard" libraries.
  - scns 6y ago
    Tablecloth uses Belt for JS targets
    - jeremy_wiebe 6y ago
      That sentence makes no sense to me as someone who’s never used Reason/ReScript.
  - nobody0 6y ago
    It's certainly confusing, it's a small niche. It may just cater to people who already know functional programming. The majority will stuck in JS anyway to get the job done.
atom_arranger 6y ago
I find the dropping of native compilation to be unfortunate. There are 3 categories of code I’m interested in writing: - Client code, must compile to JS. - Server code, ideally would compile to native. - Tooling code (e.g. Webpack / Babel replacements), ideally would compile to native. I would like to write these things in one language. ReasonML could do this, ReScript cannot.

frou_dh 6y ago

Here's a great comment explaining all the permutations: https://news.ycombinator.com/item?id=25426438 https://news.ycombinator.com/item?id=25426438 At least from a branding perspective, it seems the whole thing has been quite bungled. But obviously what's more relevant is how well the technical goals actually get met.

globuous 6y ago
Generally speaking, I am pretty happy with the (small) syntax changes from Reason to Rescript [1]. No necessary semi-colon, arrays, object declaration & access. We can finally pattern match on arrays [2] which I think was not possible with Reason (only lists were). However, there are no custom infix operator with Rescript [1], which is quite sad as it makes monadic code cleaner, whereas they were supported by ReasonML. [1] https://rescript-lang.org/docs/manual/latest/migrate-from-bucklescript-reason https://rescript-lang.org/docs/manual/latest/migrate-from-bu... [2] https://rescript-lang.org/docs/manual/latest/pattern-matching-destructuring#match-on-array https://rescript-lang.org/docs/manual/latest/pattern-matchin...
richeyryan 6y ago
A couple of years ago I was a big advocate of ReasonML and went so far as to run a meet up. I honestly believed in the technical value of it and saw it as a better alternative to Typescript. At the time, the waters were muddy enough with Reason, Bucklescript and OCaml but you could explain it away. The rebrand and change of syntax that came with Rescript was the end of the line for me. Issues like async await have gone unaddressed for years and instead the community is caught up on syntaxes and compilation targets. I turned to Clojurescript since. It solved most of it's problems years ago and its functional enough that I don't miss the static types. The large standard library also avoids the questions around whether you should use Belt or Tablecloth or any of the other "standard" libraries.
- scns 6y ago
  Tablecloth uses Belt for JS targets
  - jeremy_wiebe 6y ago
    That sentence makes no sense to me as someone who’s never used Reason/ReScript.
- nobody0 6y ago
  It's certainly confusing, it's a small niche. It may just cater to people who already know functional programming. The majority will stuck in JS anyway to get the job done.

atom_arranger 6y ago

I find the dropping of native compilation to be unfortunate. There are 3 categories of code I’m interested in writing: - Client code, must compile to JS. - Server code, ideally would compile to native. - Tooling code (e.g. Webpack / Babel replacements), ideally would compile to native. I would like to write these things in one language. ReasonML could do this, ReScript cannot.