5 ms·

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), a

by m0meni 9y ago

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.

k__ 9y ago
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 https://github.com/Schmavery/reprocessing
- m0meni 9y ago
  Reprocessing looks amazing, and I might give it a second try now. Thanks!
- thangngoc89 9y ago
  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/
- simplify 9y ago
  The interop is a bit cumbersome, but fortunately someone only has to do it once, like writing TypeScript interface files for existing libraries.
Nelkins 9y ago
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/ http://fable.io/ [1] http://fable.io/docs/interacting.html http://fable.io/docs/interacting.html [2] https://www.npmjs.com/package/ts2fable https://www.npmjs.com/package/ts2fable
- Royalaid 9y ago
  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.
  - aaron-lebo 9y ago
    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.
    - yawaramin 9y ago
      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.
    - iLemming 9y ago
machiaweliczny 9y ago
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.
aaron-lebo 9y ago
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.
- bsansouci 9y ago
  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.
  - aaron-lebo 9y ago
    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.
- yawaramin 9y ago
  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.
bsansouci 9y ago
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.
- jordwalke 9y ago
  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.

by m0meni 9y ago

k__ 9y ago

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 https://github.com/Schmavery/reprocessing

m0meni 9y ago
Reprocessing looks amazing, and I might give it a second try now. Thanks!
thangngoc89 9y ago
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/
simplify 9y ago
The interop is a bit cumbersome, but fortunately someone only has to do it once, like writing TypeScript interface files for existing libraries.

Nelkins 9y ago

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/ http://fable.io/ [1] http://fable.io/docs/interacting.html http://fable.io/docs/interacting.html [2] https://www.npmjs.com/package/ts2fable https://www.npmjs.com/package/ts2fable

Royalaid 9y ago
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.
- aaron-lebo 9y ago
  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.
  - yawaramin 9y ago
    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.
  - iLemming 9y ago

machiaweliczny 9y ago

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.

aaron-lebo 9y ago

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.

bsansouci 9y ago
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.
- aaron-lebo 9y ago
  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.
yawaramin 9y ago
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.

bsansouci 9y ago

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.

jordwalke 9y ago
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.