1. 34
  1.  

  2. 13

    This is a very welcome development. We have been using Reason, native OCaml, and BuckleScript in production for at least three years and ReScript transition has been a big worry for us.

    OCaml 4.12

    BuckleScript’s (an OCaml compiler fork) transition from 4.02 to 4.06 took a long time. Using ancient versions of OCaml meant that tooling and library support suffered. It seems like ReScript might not follow new OCaml releases anymore so it is great news that we get to receive updates to the compiler when targeting JavaScript (our main use case, and we prefer this over js_of_ocaml)

    New Reason versions

    ReScript is stuck on an old Reason version and will no longer update its refmt binary. We were working around this by using reason-repacked but support for this is getting removed next release and we won’t be able to upgrade to new compiler releases as we use new Reason features. This has been an overall trend over the years for us. Tooling and features we rely on slowly rot or get removed, and eventually, workarounds stop working.

    Dune and Esy support

    Building native Reason apps, I got to use these awesome tools and BuckleScript way of managing your builds and dependencies felt primitive over the years. It is great to see the promise of reconciliation with advancements in OCaml ecosystem.

    This will also allow us to keep using existing libraries, do code sharing and continue taking advantage of PPX’es to extend the language.

    Merlin and ocamllsp support

    Merlin with Emacs has been my dream development environment for the longest time. I used to be able to use Merlin with BuckleScript, but that was a big hassle and got worse over the years, eventually stopped working altogether. There is no Emacs support for ReScript (or OCaml/Reason with BuckleScript) anymore. I grudgingly switched to VSCode and unstable reason-language-server. New rescript-language-server which is a bit better but it has fewer features and less stable than ocamllsp, plus it has no Reason or OCaml syntax support. I made a Pull Request adding Reason syntax, which was rejected (wasn’t even that big of a change, but didn’t fit the vision).

    I’m excited for Merlin and (upcoming) ocamllsp support as I’ll be able to have the same great development experience I have with native Reason (and used to have with BuckleScript).

    Community-led development and the future

    I advocated Reason and BuckleScript, onboarded teams, and shipped software with it over three years and multiple companies, and now I’m working full-time with them. It goes to say that I repeatedly felt unwelcome when I tried to contribute code or feedback to BuckleScript, and ended up having to be a silent (and happy) user of it.

    I’m excited to have an alternative path of refuge that is actively maintained and that I can contribute to and keep using. I think this is the best outcome for both projects, this way new and old users who want ReScript to be something else than it is now will have a happy and safe environment to exist while ReScript language can follow the new vision without being held back by users dissatisfied by the transition it is going through.

    Just like js_of_ocaml and BuckleScript at the beginning, projects should be able to have different goals and co-exist. I’m sure ReScript will have success following its path to be a not-so-FP-focused alternative to JS and TypeScript with a stronger type system. I don’t know what name and shape this fork will take in the future, but just like the successful BuckleScript fork of OCaml I hope it can create a healthy and sustainable community that can stand on its own.

    It is slightly worrying that there are now threats from ReScript side about switching to a non-free license to prevent this fork from receiving updates, this is not in the spirit of open source and a bit weird since ReScript is itself a fork of OCaml. But these things were said on Twitter and Discord in the heat of the moment, and I’m sure we’ll have a healthy discourse soon and things will settle down. I wish anmonteiro the best of luck. This project has my support and I will do my best to contribute to it moving forward.

    1. 2

      I really hope the hostile closing of the rescript source does not happen! I’m a huge ocaml fan, but I was planning on exploring rescript too because I’m excited by their philosophy of “give up on some ocaml compatibility because we want to focus our efforts on making the generated code as close to optimal handwritten javascript as possible”, where “optimal” also covers things like code size and readability.

      if they don’t want to play nice with others I won’t waste my time, but ideally both rescript and this bucklescript fork will succeed and help grow the ocaml-in-the-browser pie, rather than fighting over slices of the existing one.

      1. 2

        I’m sure ReScript will have success following its path to be a not-so-FP-focused alternative to JS and TypeScript with a stronger type system

        From what you are saying it looks like, if I want a FP language, I’d be better off staying with BuckleScript, F#, PureScript or GHCJS … and avoid languages like Elm and what ReScript is becoming.

      2. 8

        Focusing almost excusively on the “ReScript syntax”

        Wait, so there was the OCaml-to-JS thing and the OCaml-alternative-syntax thing but the OCaml-to-JS developers also made their own third alternative syntax now?

        What is going on? Why.. how do people even have the energy and motivation for making alternative syntaxes at all?!

        Oh, also, if this fork also adds support for ES6 classes, I might finally start paying attention to this space…

        1. 4

          how do people even have the energy and motivation for making alternative syntaxes at all?!

          Perhaps this post will help supply the reasoning https://rescript-lang.org/blog/bucklescript-is-rebranding

          if this fork also adds support for ES6 classes, I might finally start paying attention to this space…

          It won’t, as far as I can tell. BuckleScript or ReScript have never targeted ES classes, and I don’t see that happening in future.

          1. 4

            My guess is that the only people who care about alternative syntaxes at all are people trying to get other JS developers to work with them on projects that use OCaml solely as a JS frontend, and some of them thought ReasonML doesn’t take it far enough.

            I’m not aware of any OPAM package that would be using the ReasonML syntax. All “ReasonML packages” I’ve seen are only on NPM and built with BuckleScript. I also haven’t seen any serious efforts to produce NPM equivalents of even the most popular OPAM packages.

            Effectively there have always been two independent ecosystems: one writing mainline OCaml syntax and compiling it to native code with the mainline OCaml compiler (or to JS with js_of_ocaml), the other one using BuckleScript.

            I’m glad to see that ReScript is now openly an OCaml fork since it will not confuse newcomers. Still waiting for ReasonML to write “ReasonML is an alternative concrete syntax for OCaml” on their front page though. ;)

            Regarding this BuckleScript revival, I guess it only confirms my theory regarding independent ecosystems: they only didn’t stay in sync with the mainline because they didn’t need to, since they have been using it as an isolated language that targets JS in practice.

          2. 4

            This stuff is all-too-confusing. I literally gave up on trying to learn OCaml outside of systems stuff because of the sheer name and feature related complexity of this space.

            1. 4

              This is all about OCaml on the JS platform though, if you focus on the native platform it’s super stable.

            2. 4

              What’s the advantage of using ReScript, when you can use something like F# (an underestimated language) in both backend and frontend, not to mention with WASM support and decent server remoting? cf. https://fsbolero.io/

              1. 8

                Can’t say about ReScript, but here goes for OCaml: F# on linux is still very new (using dotnet core) and I’m not sure what the open source ecosystem (not the windows one) looks like. OCaml can also be used on frontend and backend and is quite robust, if sometimes quirky. I’m not sure if OCaml is more or less underestimated than F# :-)

                1. 3

                  Do you have some links I can checkout to understand the current state of full-stack web development in OCaml?

                  F# on linux is still very new (using dotnet core) and I’m not sure what the open source ecosystem (not the windows one) looks like

                  I’m just starting to look at F#, and it works decently on VSCode with Ionide plugin. Also, the F# team has announced that they are going to improve the OSS story further. From the F# 5.0 announcement post,

                  We also plan on making significant F# tooling improvements over time. We’ve already started this work. One of the first steps was to incorporate FSharp.Compiler.Service into our build and packaging infrastructure so that any consumers of this package (e.g., the Ionide plugin in VSCode) can simply add a NuGet feed and get nightly updates. Next, we’ll work towards retiring the FSharp.Compiler.Private project, which is functionally equivalent to FSharp.Compiler.Service, so that all F# tooling consumes the same functionality in the same way. From there, we intend on working with the F# community to eventually harden the F# LSP implementation so that it powers all F# editor tooling (including Visual Studio). The long-term goal is that all F# tools have consistent behavior and feature availability, with individual editors adding their own “flavor” and unique feature set on top of that behavior so that F# programmers can pick the tool they like the most.

                2. 5

                  Compile speed (milliseconds incremental), fast and efficient editor plugins, quality of JS output (seriously try out some simple examples and compare), onboarding JS devs onto a bit more familiar syntax (parentheses & curly braces), and close relationship with underlying JS/npm ecosystem, e.g. high-quality bindings to React.js, Next.js, Tailwind, and many other libraries/frameworks.

                  If your primary focus is on staying in the F# ecosystem, then Fable is a decent choice. For every other use case, ReScript is the obvious choice. Btw, last time I checked, Bolero or Blazor and everything outside C/C++/Rust produces super bloated WASM output and they will continue to until the runtime ships with a garbage collector.