I'm on the Facebook Reason team, and we're using BuckleScript to compile OCaml into the <i>best</i> compiler output I've ever seen. People didn't recognize that my React components were generated, not hand-written.<p>BuckleScript's author (hongbo_zhang here) has been incredibly responsive and welcoming.<p>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 <a href="https://gitter.im/facebook/reason" rel="nofollow">https://gitter.im/facebook/reason</a>
I am one of the authors of BuckleScript, you can try BuckleScript in the browser: <a href="http://bloomberg.github.io/bucklescript/js-demo/" rel="nofollow">http://bloomberg.github.io/bucklescript/js-demo/</a><p>Click Examples see how the JS code generated, questions are welcome!
I've been following Bucklescript's development from the sidelines for the last couple of months along with Facebook's Reason (<a href="https://facebook.github.io/reason/javaScriptCompared.html" rel="nofollow">https://facebook.github.io/reason/javaScriptCompared.html</a>).<p>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.<p>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!
I was wondering about the practical differences between BuckleScript and js_of_ocaml. Found this brief explanation in the docs[0]:<p>> Js_of_ocaml takes lowlevel bytecode from OCaml compiler, BuckleScript takes the highlevel rawlambda representation from OCaml compiler<p>I presume that means different (higher-level) optimisations are available in BuckleScript?<p>> Js_of_ocaml focuses more on existing OCaml eco-system(opam) while BuckleScript’s major goal is to target npm<p>Now <i>that</i> 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.<p>> 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.<p>Would it ever be feasible to support interop with js_of_ocaml?<p>[0]: <a href="http://bloomberg.github.io/bucklescript/Manual.html#_comparisons" rel="nofollow">http://bloomberg.github.io/bucklescript/Manual.html#_compari...</a>
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.<p>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.<p>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.
I've just started learning OCaml. Bucklescript as well as F* and Reason are the reasons I chose OCaml over F#<p><a href="https://www.fstar-lang.org/" rel="nofollow">https://www.fstar-lang.org/</a>
Here's a talk the BuckleScript author recently gave on it.<p><a href="https://www.youtube.com/watch?v=LC3KKHYbSQQ" rel="nofollow">https://www.youtube.com/watch?v=LC3KKHYbSQQ</a>
Very cool!<p>I'm surprised by this one:<p><a href="https://bloomberg.github.io/bucklescript/js-demo/#Curry_Optimization" rel="nofollow">https://bloomberg.github.io/bucklescript/js-demo/#Curry_Opti...</a><p>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.<p>Anyway, again: very impressive. Thanks.<p>EDIT clarification: I expected:<p><pre><code> function f(param) {
return curry(32, param);
}
</code></pre>
(or is this to highlight the difference between currying and partial function application?)
It looks like tail call optimization only works in simple situations.<p><pre><code> 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);
}
}
</code></pre>
It would be nice to get a warning when tail calls cannot be optimized.
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.<p>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.
Since it has a significant overlap with Fable (<a href="https://fable-compiler.github.io/" rel="nofollow">https://fable-compiler.github.io/</a>), a comparison would be interesting.
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?
Previously called OCamlScript? The GitHub link at <a href="https://news.ycombinator.com/item?id=10860815" rel="nofollow">https://news.ycombinator.com/item?id=10860815</a> now goes to Buckle.