What is ReasonML?

[2017-11-29] dev, reasonml
(Ad, please don’t block)

This blog post gives a brief high-level explanation of Facebook’s new programming language, ReasonML.

Blog posts in this series  

  1. What is ReasonML [this blog post]
  2. Getting started with ReasonML
  3. What is planned for ReasonML?
  4. Basic values and types
  5. let bindings and scopes
  6. Pattern matching: destructuring, switch, if expressions
  7. ReasonML: functions

What is ReasonML?  

ReasonML is a new object-functional programming language created at Facebook. In essence, it is a new C-like syntax for the programming language OCaml. The new syntax is intended to make interoperation with JavaScript and adoption by JavaScript programmers easier. Additionally, it removes idiosyncrasies of OCaml’s syntax. ReasonML also supports JSX (the syntax for HTML templates inside JavaScript used by Facebook’s React framework). Due to ReasonML being based on OCaml, many people use the two names interchangeably. The following diagram shows how ReasonML fits into the OCaml ecosystem.

This is how ReasonML fits into the OCaml ecosystem.

At the moment, ReasonML’s best supported compilation target is JavaScript (browsers and Node.js).

This is what ReasonML code looks like (example taken from ReasonML’s online playground).

type tree = Leaf | Node(int, tree, tree);

let rec sum =
    fun
    | Leaf => 0
    | Node(value, left, right) => value + sum(left) + sum(right);

let myTree =
    Node(
        1,
        Node(2, Node(4, Leaf, Leaf), Node(6, Leaf, Leaf)),
        Node(3, Node(5, Leaf, Leaf), Node(7, Leaf, Leaf))
    );

sum(myTree) |> Js.log;

The benefits of OCaml  

ReasonML’s foundation, OCaml, brings the following benefits:

  • It is an established language (created in 1996) that has proven itself in many projects. Facebook itself is using it in several projects (e.g. Flow).
  • Its core is a functional programming language with a full-featured type system. But it also supports object-orientation and mutable state.
  • It can be compiled to either bytecode, fast native code or JavaScript.
  • Compilation to JavaScript is fast. Quoting the blog post “Messenger.com Now 50% Converted to Reason”:

    Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is <100ms on average. The BuckleScript author estimates that the build system should scale to a few hundred thousands files in the current condition.

Improving OCaml  

The ReasonML team also aims to improve the OCaml ecosystem:

  • Better tooling (testing, documentation, editor support, etc.).
  • Better interoperation with JavaScript. The ReasonML-to-JavaScript compiler is already very fast and produces relatively readable code.
  • Better standard library (there is a fair amount of competition in this space in OCaml, without a clear winner). Here, the goal is also to use camel-cased names (StringUtilities, createResource). OCaml uses snake-casing for lowercase names (create_resource) and camel-casing for uppercase names (StringUtilities).

Conclusion  

ReasonML feels much like what you’d get if you cleaned up JavaScript and turned it into a statically typed functional programming language. I’m ambivalent about JSX in ReasonML – it has pros and cons. I’m glad that ReasonML doesn’t reinvent the wheel and is strictly based on the established OCaml.

OCaml’s pragmatism means that you don’t get some of the more fancy functional features (that, e.g., Haskell has), but it also leads to fast compilation, efficient code and decent error messages.