JSCaml: A compile-time transformation from JavaScript to OCaml | Hacker News Reader

JSCaml: A compile-time transformation from JavaScript to OCaml

github.com

134 pointshenridf30 comments

Nice to see FB investing so much in OCaml, hope it is not just a phase like how they did with D

And I sure hope Parallel OCaml gets done

I believe I saw a video for Yaron Minsky (jane street, real world ocaml), where he said that two areas where ocaml can improve is parallelism and having a nice GUI Library

When did FB invest in D?

http://forum.dlang.org/post/l37h5s$2gd8$1@digitalmars.com

Not sure of the full time line but they hired Andrei Alexandrescu after he started working on D, and he was pretty open about using D at Facebook.

Pretty sweet if I understand that this is a front-end for the OCaml compiler! This means you could run your typed JS on OCaml's runtime instead of Node.js. Granted, the availability of npm packages will be small since most of them aren't typed by Flow but in theory you could use OCaml libraries?

Or you could just write Reason I suppose. :) There's a crazy permutation of ways to write code that can run in a browser or server run time these days!

> There's a crazy permutation of ways to write code that can run in a browser or server run time these days!

Unfortunately the state of tooling and runtime support is far behind the idealized closure of the transpilation graph.

They give two reasons to use this, but I guess another would be that you want to run the same Javascript code both on the client and the server, and your server is running OCaml.

Would they support this scenario?

In my fever dreams, it means all the world's javascript will become OCaml instead, running on the server and the browser

praise science.

To be honest, as much as I like Ocaml I think half of programmers won't be able to learn it. At least not to its full extent (monads, functors, GADTs). There's a reason functional programming never took off in the mainstream.

Any programmer who can put a loop together can learn OCaml and Haskell and Idris and Agda and APL. It is just that it takes time and effort.

It won't be a cakewalk like when we first began to learn imperative programming - learn through osmosis and unstructured play.

It would be more like learning maths, or playing an instrument from the very basics. You have to work through basic problems, read a lot, practice a lot, and slowly build up your intuition. Over time a -> b -> c will feel natural to you, you'll be able to write pattern match expressions without thinking about it, and will be astounded by your own cleverness when you're able to express things elegantly using types.

I've been trying to learn Typed FP for the last six months, and it is opening up slowly but surely. I'd recommend this path to anyone who's been programming for a while (I've been at it for 10 years now), and wondered whether this was all there was to it. Beyond these ever-changing APIs and fads and thought-leaderships, there is a whole new world of programming out there in the Typed FP community.

You should check it out. It'll make you confident to tackle larger and harder problems and maybe bring the fun back into programming. OCaml and Reason and BuckleScript is a great starting point - the community is nice and welcoming. Real World OCaml by Minsky, Madhavapeddy, and Hickey is a text with a lot of insights. You can also go straight to Haskell, but its web-browser story is not as good as OCaml's (thanks to BuckleScript). Or there is PureScript - for which IMHO you'd probably need to already know some Haskell.

(Wrote this and realized I was talking to people who'd think that OCaml is hard, not the parent)

> Any programmer who can put a loop together can learn OCaml and Haskell and Idris and Agda and APL.

> I've been trying to learn Typed FP for the last six months, and it is opening up slowly but surely.

Yes, exactly. Every kind of programming is just programming and if you already succeeded in learning one kind you should be able to learn any other kind of programming with enough effort.

The problem is in convincing enough people that a) the effort required is not that great or b) that the particular kind of programming is worth knowing despite the effort required or both.

> There's a reason functional programming never took off in the mainstream.

Sure. The main reason is a substandard (and I'm being very generous here) way FP - and more generally, programming - is taught. Take a look at http://fsharpforfunandprofit.com/ - it describes all the "hard" FP concepts in an interesting and easily digestible fashion.

Usually compilers are going from something nicer like OCaml to something janker like JS or C. Interesting to see the other way around for a change.

Does this mean the new React fiber which is written in flowtype could be compiled to OCaml? Could be useful for a native React Reason.

Pretty neat project. I for one am happy to see more OCaml in the wild. Minor nit: they mispelled jscaml as "jcaml" here https://github.com/facebookexperimental/JSCaml/blob/master/R...

Hi I'm Jordan and I work on Reason(http://facebook.github.io/reason), and previously worked on ReactJS(https://facebook.github.io/react/), so this touches on a lot of things that are of interest to me. We currently use the OCaml language with the Reason frontend, for UI development, and use BuckleScript for compiling it to JavaScript. To some it might seem like this JSCaml project might be "backwards" in that it compiles from JS to OCaml, instead of the other way around, but both of these share one important / valuable thing in common - they use exactly one memory system, allocator, collector between two different languages. This is very different than embedding a separate VM/language/allocator as a library inside of another language runtime. If you've ever tried to bridge two completely different memory systems together without introducing leaks, you'll quickly realize why JSCaml gets the most important thing right, even if it is missing some JS language features - those missing features can be added over time, whereas unifying two inherently incompatible memory systems can be bankruptingly expensive.

Seamless memory lifetime interop without leaked cycles is essential for incrementally moving a code base from one language to the other. In browsers, that means your only hope is to target semi-idiomatic JavaScript if you want to incrementally move a large JavaScript system to another language. Wasm is currently great for whole-program rewrites from scratch, not incrementally moving over. That's why BuckleScript has been so helpful.

When not running in the browser, you have many more options, and if given the choice between running Reason/OCaml in a JavaScript VM, vs. running JavaScript in an ocamlopt runtime, the later offers many compelling advantages.

1. The ocamlopt runtime allows languages with sound static guarantees to take advantage of those guarantees to emit more efficient machine code, reaching the language's full potential. JavaScript will have to go through all the same dynamic (costly) checks due to its language complexity - at least for object property/method dispatch, but why should that mean that OCaml should have to as well? By running inside of the ocamlopt runtime, it can share one memory system without being limited by an unrelated dynamic language's weaknesses.

2. Depending on the approach, the emitted JavaScript might be able to take advantage of many of ocamlopt's ahead of time optimizations to reduce allocations, and inline function calls (F-lambda for example) without having to wait for the JIT to reach many of the same conclusions (which slows down startup time).

3. Even if the JavaScript compiled to ocamlopt runtime doesn't demonstrate as much throughput as it would with a JIT (once you wait for it to warm up of course), the approach of JSCaml allows you to seamlessly break off bottlenecks and write them in Reason/OCaml which could end up running even faster than JS with a JIT once warmed up (and without having to wait for the slow JS VM's startup initialization).

I'm sure there's a ton of work left on JSCaml until you can one-click deploy your JS programs and see performance wins, but I'm very interested in this general direction, as it has many uniquely compelling advantages that stand to help move the JavaScript ecosystem forward.

Very interesting! Where can I more details in building UI with Reason?

It's all quite in early stage, but this is an example (UI in React) that speaks pretty much for itself:

https://github.com/chenglou/reason-react-example/tree/master...

This code is both very pretty and very terse, in my eyes.

I quite enjoyed playing with Reason and would love to get a chance to use it for something at work. We use a ton of Scala on the backend here at Verizon Labs (so many of us are into hardcore FP) but we occasionally run into GC issues, so the OCaml runtime is something that could potentially mitigate that.

Can you talk about what FB uses Reason to develop, and what kind of services are being built with it?

Hi Jordan, a bit off topic and late, but do you have any update on chenglou's comment on this thread:

https://news.ycombinator.com/item?id=12400397

that React bindings for Reason would be published on HN in a few days. I know there has been a lot of work in the repos for Reason for JSX support etc, but is there a public story about this yet anywhere that I've missed?

Thanks for any more info.

Hi, thanks for your interest.

You can check out the development here: https://github.com/chenglou/reason-react-example

Cheng also gave a talk at ReactConf about our efforts.

Things are still quite in flux, but you're welcome to contribute and help improve things.

Not to demotivate anyone / anything, but this sounds like the least useful parts of both worlds; programming JS (and having to deal with typing and correctness with other tools) to run on the OCaml runtime (which as noted, is really only better on a small subset of devices).

On the other hand, cool to see the investment in OCaml, and such a popular language able to run on its runtime! I hope that with all this newfound interest from the industry and the community more OCaml resources and more development in the compiler start to happen!

But how else is Facebook going to cross the extra mile to get on your baby monitor and keep track of truly everything you do?

> if you are interested in running benchmarks, you'll probably find that existing JavaScript JIT compilers are more than a match for the OCaml code produced by JSCaml.

> So why would you use JCaml at all? Two reasons come to mind:"

> You want to run your JavaScript code on small devices where JIT compilers are not available or do a bad job. > If you are actually writing your code in Reason but you want to make use of JavaScript libraries and you also want to run on small devices.

So is this aimed at use in react native? Or IOT?

Be interesting to see the JS to OCaml output put back through an OCaml to JS compiler just to compare it to the original.

Seems like it would make more sense to go the other way around... who voluntarily writes in JS to compile to some other language, as opposed to writing in any of however many dozens of other less horrible languages (but maybe typed JS is better? never tried it) to compile to JS?

I think the target use case is an existing JS library that you want to use from an OCaml/Reason program but don't want to port... OK maybe this is a very narrow use case.

Actually that makes a lot of sense now that you mention it---given the huge number of JS libraries, and the fact that unlike other languages with massive library ecosystems (cough cough Python) JS libraries are all written in JS, that does seem like a nice cheap way to expand the set of libraries available to a nice language...

JavaScript, OCaml, Reason, BuckleScript – such a language ouroborus!

It's amazing how this kind of language interoperability can enable new development and deployment approaches.

Just wait until you see my Java implementation called jocaml. It's smokin'

Please pick another name, as JoCaml[0] already exists, it is an OCaml with join calculus.

[0]: http://jocaml.inria.fr/

Reply on news.ycombinator.com