
JSCaml: A compile-time transformation from JavaScript to OCaml - henridf
https://github.com/facebookexperimental/JSCaml
======
systems
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

~~~
dvorak365
When did FB invest in D?

~~~
stonemetal
[http://forum.dlang.org/post/l37h5s$2gd8$1@digitalmars.com](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.

------
rubiquity
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!

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

------
amelius
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?

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

praise science.

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

~~~
jasim
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)

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

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

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

------
shanemhansen
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...](https://github.com/facebookexperimental/JSCaml/blob/master/README.md)

------
jordwalke
Hi I'm Jordan and I work on
Reason([http://facebook.github.io/reason](http://facebook.github.io/reason)),
and previously worked on
ReactJS([https://facebook.github.io/react/](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.

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

~~~
cies
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...](https://github.com/chenglou/reason-react-
example/tree/master/src/todomvc)

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

------
aylmao
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!

~~~
moron4hire
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?

------
kristianp
> 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?

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

------
paultopia
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?

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

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

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

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

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

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

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

