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
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
Basically, just a new syntax and a blessed-stack approach that really, really emphasizes developer experience. Which is to say, ReasonML is merely a cosmetic and DX change, it remains compatible and is not a fork of OCaml at all.
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".
Sounds great. Will this be announced on any email list I could subscribe to? Thanks!
Click Examples see how the JS code generated, questions are welcome!
I think between modular implicits[0], multicore support (both coming soon), along with BuckleScript and js_of_ocaml, Ocaml will be the functional language to beat in the coming years.
0. For those unfamiliar with modular implicits (Scala has them), they are kind of like type classes, so we won't have to write things like "print_string" or "print_int" anymore; we can just write "print".
Edit: NEvermind, I see you're compiling the lambda IR. So hopefully support for modular implicits will be automatic!
Since you mentioned Scala ... you realize Scala has had those properties for years, don't you?
One question here: how tight the compiler is binded to OCaml semantics? Besides Reason, do you think it's possible to build a frontend for other languages and integrate the backend of BuckleScript to generate beautiful JS as well? Or in other words, what property do you think a language should have so we can generate this level of beautiful JS outputs?
BTW: Please understand I'm not objecting OCaml, I do believe OCaml is an awesome language, but my point is: if possible, we should make this beautiful backend for generating human-readable JS more accessible than restricting it to OCaml only, shouldn't we :)
In particular, js_of_ocaml works with both core_kernel and async_kernel.
bucklescript doesn't respect the OCaml memory model and runtime semantics, which makes it incompatible with some part of the ecosystem.
Js_of_ocaml already has various features that bucklescript doesn't have: dynlink, support for concurrency libraries such as lwt and async, etc. It's also much more stable and battle-tested.
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!
> 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...
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.
Secondly, I don't really like Clojure as a language: It's strongly opinionated, and made some unorthodox (for a lisp) design choices which I dislike.
Finally, Clojurescript is really heavyweight, dragging along not only its own runtime, but also the google closure library and compiler, making the entire system more complex than it needed to be (was there any reason we needed to have a closure dependancy?).
Don't get me wrong, Clojure isn't an objectively bad language, it's just a language I personally dislike. If you have similar tastes to me, you may not like it either. OTOH, You may thibk it's The Best Thing Since Sliced Bread (TM). That's fine, I just won't agree.
All in all, kind of neat, but that is just way too many red flags for me to say I'm bursting with anticipation to use it.
I'm surprised by this one:
https://bloomberg.github.io/bucklescript/js-demo/#Curry_Opti...
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);
}
let test_curry x y = x + y + x
function f(param) {
return test_curry(32, param);
} 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);
}
}
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.