Comment by m0meni | Hacker News Reader

Comment by m0meni | Hacker News Reader

I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code.

That said, I recently tried rewriting some code, specifically a canvas-based game, in Reason, and while the language itself was amazing, the interop with the mutable JS canvas API was really annoying. To be honest though, not sure if games is what Reason is meant for so it's not a big deal. It's a great fit for React, which really leans heavily on the functional paradigms that Reason promotes.

Also given that FB has rewritten 50% of messenger in Reason, I don't see it dying any time soon. So here's hoping that it keeps growing and the tooling improves. I'd definitely like to see it become more beginner friendly, and additionally, I'd like to better understand how to interop with existing OCaml libraries and target the native platforms.

You may want to check out Fable[0] for F# if you haven't already. Syntax will be very familiar, and the interop[1] with JS is really great. There is also a tool to create bindings from Typescript declaration files[2].

[0] http://fable.io/

[1] http://fable.io/docs/interacting.html

[2] https://www.npmjs.com/package/ts2fable

Generally when it comes to interoperability with JS the problem stems from assumptions made by the people designing the JS APIs and what is idiomatic in the compiles-to-js Lang. Clojurescript, Reason, Purescript, and Elm all have a specific way they want to work and the browser APIs go against that.

If anyone has any advice on how to help this I am all ears but writing garbage interop code gets old.

I came to this conclusion over the weekend. Really wanted to use one of those compile to JS languages, but after doing some interop and looking at their output, you're fighting the browser. Even Clojurescript, which is supposed to have has great code elimination will produce much bigger outputs then regular JS.

One way to look at it is immutable.js minified is 55 KB. That's about 5,000 lines of JS. If you're using a functional language, you've gotta bring along those immutable datastructures somehow, and 5k lines of Clojure is gonna output greater than 5k lines of JS.

Keep a watch for the new Reason standard library, it will bring some stunning reductions in output code size. I mean, right now the output code size is about as minimal as you can get while looking like hand-written JS ... but what's coming might blow all the other immutable libs out of the water thanks to optimisations it can do using static typing information.

don't forget Clojurescript employs Google Closure compiler that has the best in the market dead-code elimination. Code on prod can be pretty small.

I found the interopt a bit cumbersome too, but I guess this is what you have to pay for a 100% typed codebase :/

I saw some people wrote games with Reprocessing, maybe this helps.

https://github.com/Schmavery/reprocessing

Reprocessing looks amazing, and I might give it a second try now. Thanks!

Hey author here,

Here is a successful story [1] of using reprocessing for making cross platform game (Android, iOS, macOS and Web) from Jared Forsyth

  [1] https://jaredforsyth.com/posts/making-a-cross-platform-mobile-game-in-reason-ocaml/

The interop is a bit cumbersome, but fortunately someone only has to do it once, like writing TypeScript interface files for existing libraries.

Interop was a little pain for me as well when testing ELM, so for practical reasons I'm ended using Typescript and I like it quite well but I think immutability by deafult is good step forward towards better programs and I'm happy FB engineers work on ReasonML.

One place you can see this in action is that [ ] are lists and [| |] are arrays.

JS favors arrays, OCaml lists, so you either write dsls with [| |] (ugly), or you import a module and convert from lists to arrays and your bundle size goes up 80 KB (don't recall if minified or not).

I was surprised to see Reason continue with this syntax. The idiomatic approach for either side is suboptimal unless I'm missing something.

What DSLs are you referring to here?

One reason to favor lists over arrays has been that they are immutable. Most of my personal JS array usages have been as dynamically sized arrays, because I’ll use .push all over the place. That usecase is the primary reason to use lists instead: it’s much faster to prepend and destructure on lists.

Something like Elm's Html module:

    div [ id "test" ] [ text "stuff" ]

vs

    div [| id "test" |] [| text "stuff" |]

If the JS library expects an array (not uncommon), that gets ugly quickly.

Hi, I'm pretty sure a tree-shaking bundler like Rollup can wipe out most of that bundle size by using only the list functions you need. Then again, if you need to use arrays, use arrays, [|1, 2, 3|] is not actually that bad–you get used to it pretty quickly.

I’d love to hear about better interop APIs. I think if there’s any way to make Bucklescript bindings easier, that would be tremendous.

In my experience, the crux of the difficulty actually comes from the JS APIs themselves working in a very JS-way, to be nice. Lots of DOM APIs rely on the dynamically typed nature of JS, making it super hard (probably impossible) to make statically typed bindings to.

The main advantage of building on the OCaml language is that it is possible to totally encapsulate an FFI binding in a way that doesn’t virally infect the code path that calls into it. In pure languages this may not be the case. OCaml is not a pure language and so neither is Reason.

Reply on news.ycombinator.com