
Announcing BuckleScript 1.0 - e_d_g_a_r
http://bloomberg.github.io/bucklescript/blog/index.html
======
chenglou
I'm on the Facebook Reason team, and we're using BuckleScript to compile OCaml
into the _best_ compiler output I've ever seen. People didn't recognize that
my React components were generated, not hand-written.

BuckleScript's author (hongbo_zhang here) has been incredibly responsive and
welcoming.

We'll be publishing the React.js binding on HN in a few days. Stay tuned! We
(including Hongbo) are all sitting in irc #reasonml and
[https://gitter.im/facebook/reason](https://gitter.im/facebook/reason)

~~~
danielmason
Reason describes itself as "a meta language toolchain to build systems
rapidly", which seems a little vague to me. Am I understanding correctly that
Reason is both a (kind of) alternative compiler for OCaml's build toolchain,
and a dialect of OCaml in its own right?

To tie this back to Bucklescript, does this loosely describe the process of
using Reason syntax to author Javascript? Reason file -> (Reason) -> OCaml
executable code -> (Bucklescript) -> Javascript

~~~
chenglou
Think Elixir for Erlang.

Currently it's a syntax on top of OCaml. But we'd like to polish the OCaml
ecosystem tooling too; we're calling the umbrella project "Reason".

~~~
jonahx
> Currently it's a syntax on top of OCaml.

Does this just mean it compiles to OCaml?

~~~
chenglou
There's a crucial distinction! OCaml's compilation command takes in a `-pp`
flag (preprocessor), which accepts a command that takes in a file and outputs
an OCaml AST tree. We're basically using that. In that sense, the official
OCaml syntax is really just that: another syntax like Reason, but official,
and goes back two decades.

Because of the clean mapping from one syntax to another, you can toggle
between the two fairly easily:
[https://github.com/facebook/reason/wiki/Newcomer-
Tips-&-Tric...](https://github.com/facebook/reason/wiki/Newcomer-
Tips-&-Tricks#ocaml---reason-conversion-tricks)

~~~
jonahx
Interesting. Thanks for explaining that.

------
hongbo_zhang
I am one of the authors of BuckleScript, you can try BuckleScript in the
browser: [http://bloomberg.github.io/bucklescript/js-
demo/](http://bloomberg.github.io/bucklescript/js-demo/)

Click Examples see how the JS code generated, questions are welcome!

~~~
kandalf
Very neat. Can BuckleScript compile Core?

~~~
Drup
If you want to use the OCaml ecosystem, use js_of_ocaml. It has much better
compatibility and there is no perf difference.

In particular, js_of_ocaml works with both core_kernel and async_kernel.

~~~
yminsky
Indeed, js_of_ocaml is kind of shocking in its fidelity. It can compile even
highly complex libraries that do lots of runtime tricks. Async_kernel and
Incremental_kernel both compiled and worked without any issues whatsoever.

We've even built some support for making incrementally rendered web-apps in
OCaml, using Async and Incremental. Here's a link:

[https://github.com/janestreet/incr_dom](https://github.com/janestreet/incr_dom)

It sounds like Bucklescript is doing something quite different, which is to
aim for pretty JavaScript output, while compromising and maintaining semantic
consistency with OCaml. I don't fully understand the use-case, but for us, js-
of-ocaml is clearly the thing we want.

------
kcorbitt
I've been following Bucklescript's development from the sidelines for the last
couple of months along with Facebook's Reason
([https://facebook.github.io/reason/javaScriptCompared.html](https://facebook.github.io/reason/javaScriptCompared.html)).

I'm very optimistic about the future of these two projects. Both are working
hard to build a soundly-typed platform on top of the JS ecosystem. While there
are tons of existing languages that can be compiled to JS, the most successful
ones are those (like Typescript) that embrace the npm ecosystem and the huge
community investment it represents.

Both Bucklescript and Reason have a huge focus on seamless JS interop and DX,
and stand a good chance of bringing soundly-typed functional programming to a
much wider audience!

------
evincarofautumn
I was wondering about the practical differences between BuckleScript and
js_of_ocaml. Found this brief explanation in the docs[0]:

> Js_of_ocaml takes lowlevel bytecode from OCaml compiler, BuckleScript takes
> the highlevel rawlambda representation from OCaml compiler

I presume that means different (higher-level) optimisations are available in
BuckleScript?

> Js_of_ocaml focuses more on existing OCaml eco-system(opam) while
> BuckleScript’s major goal is to target npm

Now _that_ is a good idea—npm is a fairly large ecosystem that people are
already familiar with. If you haven’t already, you might look into using
existing TypeScript interface files to get type information for npm libraries.

> Js_of_ocaml and BuckleScript have slightly different runtime encoding in
> several places, for example, BuckleScript encodes OCaml Array as JS Array
> while js_of_ocaml requires its index 0 to be of value 0.

Would it ever be feasible to support interop with js_of_ocaml?

[0]:
[http://bloomberg.github.io/bucklescript/Manual.html#_compari...](http://bloomberg.github.io/bucklescript/Manual.html#_comparisons)

~~~
hongbo_zhang
yes, it is actually easier to optimize since you have more herusitics. both
compiled to js, so yes, it can work together : )

------
qwertyuiop924
This is one of the few JS compiled languages that interest me: Some of these
languages add a very thin syntactic layer on Javascript and maybe a type
system. If I wanted Javascript, I'd use Javascript, and if I wanted types, I'd
use Flow, not a new programming language that's kinda-sorta-not-really JS.

That leaves this, Clojurescript, and SPOCK as the only really interesting
projects. They all have runtimes that are unpleasantly large (well, Buckle may
not), but that's the price of a new language.

However, Clojurescript leaves a bad taste in my mouth, and SPOCK stresses
javascript implementations in interesting ways. I'm not really a fan of OCaml,
but Buckle looks interesting, and more enjoyable/practical than the other two.

~~~
nine_k
I bet you heard about Elm and purescript?

~~~
qwertyuiop924
Forgot about those. Yeah, they're on the list. Elm seems to be the most
practical of the lot, and also one of the nicest to program in.

~~~
elbear
I've been using Elm for the last 2 weeks on a project and I love it. I still
get slapped around all the time by the compiler, but at least I know my
program won't have any run-time exceptions.

~~~
hongbo_zhang
If you like Elm, you will like Buckle too! we have a much faster compiler, and
you can compile it into native code as a bonus : )

------
magnumkarter
I've just started learning OCaml. Bucklescript as well as F* and Reason are
the reasons I chose OCaml over F#

[https://www.fstar-lang.org/](https://www.fstar-lang.org/)

~~~
zem
do you have any uses in mind for F*? i went through the tutorial a while ago,
and it looked very nice, but i couldn't think of anything i wanted/needed to
use it for.

~~~
magnumkarter
Eventually I would like to write a C Compiler with it

------
mightybyte
Here's a talk the BuckleScript author recently gave on it.

[https://www.youtube.com/watch?v=LC3KKHYbSQQ](https://www.youtube.com/watch?v=LC3KKHYbSQQ)

------
nothrabannosir
Very cool!

I'm surprised by this one:

[https://bloomberg.github.io/bucklescript/js-
demo/#Curry_Opti...](https://bloomberg.github.io/bucklescript/js-
demo/#Curry_Optimization)

Why doesn't it actually curry? Impressive output, don't get me wrong. But
given how native and idiomatic currying is in Javascript, and how much trouble
I'd expect this to have taken to implement... is there a specific reason for
this? Just curious.

Anyway, again: very impressive. Thanks.

EDIT clarification: I expected:

    
    
        function f(param) {
            return curry(32, param);
        }
    

(or is this to highlight the difference between currying and partial function
application?)

~~~
ycitm
Looks like it's just an optimization. If you change to

    
    
      let test_curry x  y =  x + y + x
    

You get the expected output

    
    
      function f(param) {
        return test_curry(32, param);
      }

------
PhineasRex
It looks like tail call optimization only works in simple situations.

    
    
        let rec foo i = if i < 0 then "foo" else bar (i - 1)
        and bar i = if i < 0 then "bar" else foo (i - 1)
    
        function foo(i) {
          if (i < 0) {
            return "foo";
          }
          else {
            return bar(i - 1 | 0);
          }
        }
        
        function bar(i) {
          if (i < 0) {
            return "bar";
          }
          else {
            return foo(i - 1 | 0);
          }
        }
    

It would be nice to get a warning when tail calls cannot be optimized.

~~~
hongbo_zhang
yes, we will have this warning when upgraded into OCaml 4.04 Note that
optimizing mutual recursive call is a very hard problem it needs VM level
support

~~~
PhineasRex
Mutual tail call optimization requires VM level support in general but can be
accomplished within a compiliation unit (module) via inlining.

~~~
michaelsbradley
Seems like it should also be possible to have the compiler employ JavaScript
generator functions (i.e. `yield`) and iteration as a substitute for growing
the stack, which might be a bit more flexible than rewriting in terms of
loops+thunks, though the concept is the same.

------
mullsork
OCaml seems to be on an upswing in popularity/hype recently. As someone who's
threading the waters in Clojure but not a fan of the JVM developer experience
I'm curious why OCaml is a great choice.

I would love to hear some stories from people using it in production. I'm
leaning towards wanting to use a LISP as it's just so elegant... but I feel
that getting boggled down in "hard core" functional programming is a bit
daunting and limiting.

~~~
mikebelanger
I'm in the same mindset right now. Really like aspects of Clojurescript and
its elegant syntax, but it's complicated machinery (JVM, Google Closure) make
me wary. I'm sure they're well done, but because I'm mainly interested in the
JS target, I'm open to something like Bucklescript, along with Elm,
Purescript.

------
kasajian
Since it has a significant overlap with Fable ([https://fable-
compiler.github.io/](https://fable-compiler.github.io/)), a comparison would
be interesting.

------
mikebelanger
The website says BuckleScript can also be compiled into a unikernel, which
links to MirageOS. I get the sense that integration between MirageOS
unikernels and the javascript Bucklscript compiles down to is a likely usage-
case scenario?

------
andrewfong
Previously called OCamlScript? The GitHub link at
[https://news.ycombinator.com/item?id=10860815](https://news.ycombinator.com/item?id=10860815)
now goes to Buckle.

~~~
hongbo_zhang
yes, it has a conflict with existing project, so it was renamed later

------
millstone
This looks really cool. How does the integration with external JavaScript
libraries work? Could I use this with something like Three.js?

~~~
hongbo_zhang
Definitely, almost half the time is spent in polishing the FFI. Check out the
FFI section in the Manual. OCaml's type system is so powerful, that it can
model most js libraries without writing JS stubs code

