A short history of ReScript (BuckleScript)

My recommendation is to use JSOO, or ReScript–not both in the same project. That sounds a bit too over the top :slight_smile:

The reason why I suggested not to use OCaml (native toolchain) in the same codebase with ReScript toolchain is–IMHO it’s not worth the effort for most people. For you, maybe it is–despite all the hacks. But there shouldn’t need to be so many hacks in a maintainable codebase. At a certain point you’re just better off using Spring Boot or whatever.

1 Like

I’m really pleased to see ReasonML finally crediting OCaml in at least some way on its front page. I would prefer it to say “ReasonML is an alternative concrete syntax for the OCaml programming language”, but that’s still better than before. I still think its website is completely confusing for newcomers who aren’t already familiar with OCaml though.

As of ReScript, I’m also happy to see it openly become a standalone language. BuckleScript essentially always was a standalone toolchain nearly impossible to integrate into an OCaml workflow, so there’s going to be a lot less confusion now, I hope. I wish the authors best of luck.

Not to distract from the rest of the thread, but jsoo doesn’t run “atop a compiled version of the ocaml bytecode interpreter”. It compiles the bytecode to javascript. There is no interpreter involved (except the browser), and the perf is usually comparable to hand-written code.

2 Likes

Running JSOO emitted javascript on v8 and mozjs can be amazingly fast in some cases. Some time ago I did a little test program solving prime numbers, using a very simple algorithm (dividing by ascending odd numbers up to the root of the tested number) and it could solve the 100,000th prime under JSOO running in the browser faster (0.29 secs for v8, 0.26 secs for mozjs) than the equivalent code running in native ocaml (0.52 secs). I guess the test case happened to hit a sweet spot for v8’s and mozjs’s JITing of the loops into optimized CPU instructions. Normally JSOO is somewhat slower than native code. (For anyone interested in the comparison, it is here: http://www.cvine.plus.com/primes.tar.xz )

4 Likes

Interesting. I ported the benchmark with some slight modifications to ReScript (OCaml syntax) and get 0.117s with Firefox and 0.094s with Chromium. I haven’t run the JSOO version for comparison, so take this with a grain of salt of course.

Here’s the repo in case you’re interested: GitHub - yawaramin/primes-rescript (requires Node.js to work). I’ve also included the output JS file for easy comparison: primes-rescript/primes.js at main · yawaramin/primes-rescript · GitHub

I believe the only significant difference is that my port isn’t using the onload event; instead, I just placed the <script> tag at the end of the <body>, which guarantees the same effect.

EDIT: sorry, one more fairly significant difference: I’m using ReScript’s built-in lightweight string interpolation, {j|Elapsed time: $time..., instead of Printf.sprintf. But I think it’s a fair showcase of ReScript’s specific advantages.

4 Likes

You have a nice fast machine. By way of comparison, how long does the native ocamlopt code take to solve the prime?

Weirdly, if I put the script tag in the body and omit the Lwt onload event, the JSOO code runs slightly slower for me. Loading it in the head seems to improve the chance of the JITer getting on the fast path, particularly if reloading the page.

Edit By the way, I don’t have rescript installed but if I tweak your rescript-generated primes.js file by omitting the imports of curry.js and caml_int32.js and substituting standard javascript, the rescript version runs slightly faster than the JSOO version in chrome and slightly slower in firefox. So it seems pretty much-of-a-muchness.

To clarify, Dark’s frontend is 50kLOC of Rescript (OCaml syntax) and will continue to be for the foreseeable future. The backend (20kLOC) is being rewritten from OCaml (native+jsoo) into F#. I’m about two months into it and approaching being finished.

Thanks for writing this! I was also extremely confused about what was happening. I had thought there was a still a reasonml project that targeted JS.

I’ll note that it feels like the OCaml syntax for rescript is a second-class-citizen, as lots of things seem to only work with the PPXes that only work on rescript.

1 Like

Hi, np. Yeah, the OCaml syntax is second-class in some ways (e.g. ReScript has nice uncurried syntax, nice JSX syntax, etc.), but ironically first-class in other ways e.g. as far as I know the OCaml syntax is still the only way to access ReScript’s conditional compilation feature (using environment variables, e.g. dbc/Yawaramin__Dbc.ml at eaddea5fe2dfa2195bbc5c2470af5e23a0f29fce · yawaramin/dbc · GitHub , the only way to define difflists using GADT syntax (e.g. Cannot parse Diff List constructor · Issue #74 · rescript-lang/syntax · GitHub ), and the only way to define JS object types that combine (‘inherit’) other object types.

Of course, this is beyond the obvious missing ‘sugar’ features like custom operators (which they are planning to introduce or rather re-introduce), and expression-level open and fun syntax which as far as I can tell they are not planning to bring back.

1 Like

I used to think that departing so much from OCaml syntax was not a good idea. But recently I had a personal epiphany: ReScript fits in the gap between Elm and PureScript.

  • While Elm is very nice, pure and symmetric; it’s too detached from reality by pretending that DOM or JS library bindings are not necessary (try using WebCrypto, WebGL or anything similar from Elm).
  • While PureScript is very powerful, pure and friendly with the rest of the JS ecosystem; from a peasant’s point of view like mine, it makes you feel like you need a degree in algebra to be able to use it effectively (I’m pretty sure the Effect monad in PureScript is still more manageable than all the equivalent stuff in Haskell).
  • ReScript is pragmatic, sound and easy to learn. I’m really curious to see how ReScript deals with the asynchronous code.

Whatever the case is, the more the merrier. Just remember that the true enemies here are conformism and TypeScript.

6 Likes

I just realized this is posted in the ocaml discussion board and not https://forum.rescript-lang.org/ where you might think it would be…

Despite that ReScript evolves as a stand alone language, I would like to say that we would like to and welcome OCaml type system experts to contribute.

The goal of ReScript is to bring an opininated subset of ML style type system more popular to the industry users. To strike an impact over the industry is our goal and we belive we have a chance. There are numerous backend languages on the market, while on the JS platform, the only choice is TypeScript. The market is large enough to incorporate several languages.

To compete with TypeScript we have lots of things to do, and if you are interested in bringing OCaml style’s type system into more users, you are welcome to contribute to ReScript.

5 Likes

while on the JS platform, the only choice is TypeScript

So Elm doesn’t count ? :slight_smile:

1 Like

Hi there @bobzhang ! I have been following the Rescript/ReasonML discussion from a distance. I believe there is value to sticking with the OCaml ecosystem but also value in striking out in a new direction. There are benefits to both approaches – it only depends on how well they are executed.

Therefore, I respect the direction you outlined in your original post on this thread. You wanted to get rid of a lot of bloat. Getting rid of ReasonML means that you can have a performant front-end end without lots of legacy, also you can customize Rescript more to the needs of the Javascript ecosystem, have better error messages etc. All these reasons make sense to me.

So I’ll get to the point: Since Rescript decided to take a slightly separate direction, understandably the Rescript community lost out on a lot of OCaml ecosystem experts. I don’t know how high the likelihood would be to attract OCaml people to work on the aging 4.06 era Rescript backend. While there is a lot of work to be done in Rescript in the future, it feels that a lot of progress was made between 4.06 and 4.13 in OCaml (and more on the way). All that work seems to have been thrown away. If I understand correctly you’re still using the old 4.06 merlin backend in the Rescript LSP also. So while your frontend is sparkling and fresh your compiler backend is aging.

Some may argue that the current rescript OCaml 4.06 backend is “good enough” – it may be good enough for now but will it be good enough 5 years from now when the whole world would be on OCaml 5.x? Who knows what directions things will take with things like Webassembly etc on the horizon? Meanwhile Rescript would still be on the 4.06 island.

Suggestion
So may I suggest a slightly different approach. Please keep your backend upto date with OCaml! The melange project GitHub - melange-re/melange: A mixture of tooling combined to produce JavaScript from OCaml & Reason by @anmonteiro which is based on OCaml 4.12 shows you can keep your backend upto date with minimal effort.

I personally don’t care if rescript front end language kept diverging from the OCaml/ReasonML – as long as you are sticking to the OCaml backend then you will have people excited to work on the Rescript compiler. Right now, the prospect of working on a 4.06 era codebase may not be very exciting to a lot of people, I think.

I don’t know the compiler internals sufficiently to know if my suggestions make sense or not. The main point I’m indicating here is that you need some sort of a concrete link with the current OCaml ecosystem for people in that ecosystem to want to contribute to Rescript.

So the Rescript front-end language can continue to diverge but it needs to have some connection that is alive with OCaml. As an example, the mirage ecosystem does not have it own forked compiler – it pulls in the latest ocaml base compiler and works with it. Can’t the rescript compiler stay upto date with the OCaml backend automatically?

Once you have some link that is alive with (modern) OCaml you will find a lot people from the traditional OCaml ecosystem wanting to contribute.

8 Likes

Fable’s js code is pretty readable and the syntax is F#. The compile speed might not as fast, but does not matter that much. Few codebase as large as FB. Rescript might have some chance in the future, but I do not think it will achieve the popularity as TS. Personally, I give up Bucklescript after the rename to rescript. Tired of learning new syntax.

2 Likes

In my opinion, Rescript can succeed in the future if it only tries to re-combine its forces with the OCaml ecosystem again. Almost a year plus into the total separation, I can imagine the huge burden on the Rescript team – they need to do everything from soup to nuts (compiler, tooling, language…). It can be daunting and I’m sure they are up to the challenge but there is no reason why their journey has to be so lonely. In my reply above I’ve suggested how they can reestablish collaboration with the OCaml ecosystem.

The difference between TS and Rescript is that Rescript has fewer compromises. Though few code bases are very huge, instant transpilation really makes things easier during development. That is a big draw for Rescript and will continue to be.

ReasonML+Bucklescript was the pride and joy of the OCaml community. By doing a total separation (albeit for honest reasons) an unintended effect of that would be have been drying of the talent pipeline from OCaml (this is an educated guess, it could be the opposite – please correct me).

3 Likes

Could someone more familiar with the OCaml compiler internals, development process, and project governance, comment on the following:

  • Would it be possible to make ReScript a first-class citizen of the OCaml ecosystem, similar to ReasonML, by adopting and maintaining the changes to the intermediate language representation that enable such high quality JavaScript emission in the mainline OCaml compiler? The ReScript team can then focus on developing the ReScript language and the JavaScript emission backend module without having to constantly maintain and update a fork of the OCaml compiler.

  • If that were a goal we can agree is important to the OCaml community (and the fact that the v3 OCaml website is being built with ReScript is a proof that we don’t currently have a better alternative), what are the roadblocks? Technical issues? Manpower?

1 Like

It appears to me that the sudden separation effectively eliminated any excitement and momentum people had for ReasonML or Rescript. People who invested in this new thing and watched it grow suddenly saw that it was flimsy, capricious and unreliable, and that the ecosystem could be destroyed rather easily. I wouldn’t blame anyone who ran away from anything to do with those languages as a result.

12 Likes

ReScript wants to control their whole toolchain (who wouldn’t want to if they can make it happen?). That was the reason they branched out in the first place.

As this approach has brought them results so far, I don’t see them doing it any other way.

1 Like

Since most people don’t see the big picture, let me explain a bit about the current status and motivations.

  • Current status:

After we integrate the whole toolchain, the bug fix can be done very quickly. And changes to the type system is trivial and we managed to speed up the whole compiler by around 20%. This is non-trivial given that ReScript compiler/build is already the fastest on the market.

The ReScript compiler also works with any modern compiler toolchain thanks to the simplification of the architecture and the maintenance is much easier. Very handy new features, e.g, unicode support, optional records will be available on next release.

These all great things happen even without a full time job.

  • ReScript and OCaml benefit each other

We would like to see OCaml having a boom community and I am excited to see the upcoming multicore landed. When I see the new website is built using ReScript, I am very happy and would be happy to prioritize the feature request from them.

Why ReScript decides to grow as its own language is that the native backend and front-end are completely two different worlds. I am excited to see multicore landed in OCaml, but it does not have any impact over ReScript.

In the history of ReScript development, we don’t see major contributions from OCaml experts, but there’s great potential, ReScript has one of the highest quality to-JS compiler (thanks to OCaml and it keeps going), contributions are more than welcome, let’s work together to bring ML to more users.

11 Likes