1. 18
  1.  

  2. 4

    I should emphasise that it’s pragmatic: you’re not forced to deal with the added mental load of monads and other type system rabbit holes

    Except that purity reduces the number of “type system rabbit holes”. OCaml gives up principal types (the “value restriction”) in order to remain sound in the presence of effects.

    1. 6

      ‘Rabbit holes’ isn’t a soundness judgment, it’s a description of the steep learning curve.

    2. 3

      With all due respect, I get the sense that the author has very little understanding of how compilers for functional languages and the execution of programs in general.

      How does bucklescript compile closures? Does running a closure result in a sequence of pointer deferences? The generated code is going to be JIT-ed at runtime by browser anyway.

      At points in the article, it feels like the author is advocating more for the speed of compilation rather than the speed of the generated code.

      If I’m wrong about any of the above points, I’ll happily be corrected. Also, in general I’m pleased to see the adoption of function languages; just felt that the argument in this article was poorly formed. Sorry to be so negative :)

      1. 9

        Hi, I am the author of the blog post. I like to think I know a little bit about functional compilers, languages and runtimes from my day job and other studies; of course I could be totally wrong. But I’ll try to answer any specific questions you may have.

        BuckleScript compiles OCaml closures simply to ES5 closures. So the following:

        let add x y = let add_x y = x + y in add_x y
        

        is compiled to:

        function add(x, y) {
          var add_x = function(y) { return x + y; }
          return add_x(y);
        }
        

        The generated closure, as you can see, is about as performant as a hand-written closure would have been.

        I definitely advocate for speed of compilation quite a lot because it’s such a transformative experience when the compiler doesn’t waste your time; but I think I also mention that the OCaml compiler and the community are obsessed with performance in general. The thing is that the language has a dead-simple runtime model; it doesn’t do fancy just-in-time compilation or other tricks. As a result, the JavaScript output looks and performs very much like idiomatic hand-written JS.

        1. 5

          At points in the article, it feels like the author is advocating more for the speed of compilation rather than the speed of the generated code.

          You are not wrong about this. If you go to BuckleScript homepage, the very first thing it wants to tell you is compilation speed. Personally I think optimizing for compilation speed makes sense in this case.