Hacker News Reader

Comment by hongbo_zhang | Hacker News Reader

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

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

View on HN

I just wanted to say thanks to the authors of Bucklescript. Not sure if I'll ever get to use it in a production system, but definitely awesome tech. I played with it a little bit and I think an OCaml React app might actually compile faster than the same thing written in ES6 and compiled/built through the normal babel+webpack toolchain.

you should checkout reason, they are working on bindings using bucklescript. So it is not a dream, people probably can write react app using ocaml very soon

Hey, so when Ocaml comes out with modular implicits (hopefully soon!), will they be supported? If I recall correctly, Bucklescript is compiling Ocaml source, as opposed to Ocaml bytecode like js_of_ocaml does [this is incorrect, see below]. Assuming this is the case, I'd guess the downside is you have to specifically work to support potentially complex new features like modular implicits.

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!

> 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.

Since you mentioned Scala ... you realize Scala has had those properties for years, don't you?

Yes, true. I'm probably overstating things. Just excited about the prospect of having these things in Ocaml. Scala is an impressive language but it's a big language. I prefer the relative simplicity of Ocaml and (even more) SML.

Also, performance-wise, with multicore and the new optimizations with flambda, Ocaml will be particularly interesting.

we still reuse ocaml's compiler tool chain. we are compiling ocaml's lambda into JS. so yes, we will support modular implicit once it is landed

Thanks for this! Really awesome stuff!

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 :)

OCaml compiler is designed in an extremely modular style. Actually you can design any syntax for OCaml (including lisp style) and produce the OCaml data structure, then it should work with BuckleScript, that's how Reason works

Are there internal projects inside Bloomberg that use this? It is really great and it is very impressive that it seems that you almost single-handedly did all this. I am curious what moved Bloomberg to start a project like this.

we have an intern this summer create bindings for our internal JS stack. we have some internal stuff running on server side in OCaml which we wish to move to client side. I would say many thanks to my boss and employer's great support

BTW, congratulations on the 1.0 milestone!

How did you become so proficient with the OCaml compiler internals? When you started the project did you already know that you can compile to idiomatic js or was that discovered through experimentation?

Thanks! I have some experience in ocaml compiler internals, I reimplemented camlp4 called Fan. Yes, I made a prototype in 2 weekends and showed it to my boss and got very good feedback

Very neat. Can BuckleScript compile Core?

It would have to be Core_kernel, the subset of Core that doesn't interact with the runtime or OS. I'm very curious about this and would like to know, too.

as long as it is vanilla OCaml (no c stubs), it should be fine

Uh, given that you don't respect ocaml's memory model and force -safe-string, that's just not true. Any Obj.magic that is correct in OCaml is probably not going to be correct in bucklescript.

Did you actually tried to compile core ?

`-safe-string` is the future. Any compiler can not guarantee its correctness if you write crazy code , `Obj.magic` here. I am not interested in core personally, but I don't see any reason why it will not work if it is vanilla OCaml

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.

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

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.

This is really cool! I took some OCaml code I'd written a while ago and pasted it in and the output was shockingly legible even with the calls to functions in stuff like Caml_int32 and Pervasives. Very impressive!

From a practical standpoint, what's the difference between js_of_ocaml?

much more readable transpiled output, really nice (and getting nicer) FFI to javascript. but it doesn't interface with existing ocaml stuff as well (doesn't use `.cmo/.cma` so it needs to compile everything from source afaict)

it is generate more readable JS. and we have spent lots of time in polishing the FFI to make OCaml/JS interaction easier

People gave you the part in favor of bucklescript, so I'll give you the other side of the story:

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.

to be precise, Js_of_ocaml does not respect OCaml memory model either, think about float. But I think Js_of_ocaml is really great, BuckleScript and Js_of_ocaml have different use cases.

Reply on news.ycombinator.com