5 ms·

25 Days of ReasonML

121 points by based2 9y ago

petetnt 9y ago
Nice article! I was also doing Advent Of Code[0] with ReasonML but sadly due to time constraints I didn't get any far. Still learned a lot about ReasonML, even if the solutions weren't really idiosyncratic! Definitely going to dive into ReasonML later again. [0] https://github.com/petetnt/advent-of-code-2017-reasonml https://github.com/petetnt/advent-of-code-2017-reasonml
vemv 9y ago
I'm interested in Reason/Buckle, coming myself from the ClojureScript. The seemingly tinier minified compilation size would be a huge plus. But what are the actual sizes emitted for large scale projects (arguably the ones that matter most for static typing)? Anyone could share real-world experiences? For reference: I know of cases where 60K lines of clojurescript (arguably equivalent to 150K lines JS) compile down to 5MB under advanced optimization mode. (in case that scares you: well it's an actually large app. We should do route-based code splitting soon - easy/robust with clojurescript apparently)
- dangerbird2 9y ago
  One thing bucklescript has going for it is that it plays nicely with the NPM/webpack ecosystem. If you want your bundled code to be optimized and minified like Clojurescript, just use a plugin/loader for webpack or your bundler of choice to run the Closure compiler or a similar javascript optimizer. Despite being more inflexible about tooling, clojurescript is great because of how it generates code specifically to take advantage of Closure's optimizaitons.
- lilactown 9y ago
  Hey, author here! BuckleScript itself doesn't actually do any sort of bundling or minification of the code - in fact, it prides itself in generating "human readable" code that, worst comes to worst, one could modify by hand and not be too hung out to dry. So in that case, you are at the mercy of the general JS ecosystem when it comes to module bundling, minification, code splitting, etc. The Google Closure compiler does a lot of the magic behind ClojureScript's advanced optimizations, so theoretically one could leverage those same optimizations with an app compiled by BuckleScript. Unfortunately, I don't have any real-world experiences with this. However, I do have experience using ClojureScript + Google Closure compiler and can give you a heads up that you might (...probably will) run into issues using Closure compiler with NPM libraries, which the BuckleScript ecosystem relies on. As someone who recently started working daily with ClojureScript, I'm really crossing my fingers for some of rough edges around Node.js/ES module support in the Closure compiler to be smoothed out soon! NINJA edit: I have heard good things about rollup with regards to dead-code elimination and other optimizations, but the JS module bundling story is moving at break-neck speed these days and I'm not really keeping up with it - Parcel's a new thing? Jaredly's writing a bundler in ReasonML?? X_X
- yawaramin 9y ago
  That's a very interesting question. We could ask some Messenger and Instagram people, since they are heavily using BuckleScript. In general output JS is already fairly spartan, because BuckleScript uses a few tricks here and there, like encoding modules and records as arrays instead of objects; and completely inlining functions whenever it can. BuckleScript also emits ES6 modules, with imports and exports, and it marks its output as either pure or impure at the module level. So potentially there's a lot of room for bundlers to do tree-shaking. Bob Zhang, the BuckleScript team lead, is working on a new typesafe standard library for BuckleScript, which takes advantage of compile-time checks to compile to extremely minimal and idiomatic JS. Exciting times up ahead!
  - Hurtak 9y ago
    I have heard about the Messenger where they have 25-50% of the web client codebase in Reason, but I have not heard about the Instagram story. Can you share more info or some links about that?
    - yawaramin 9y ago
      Hi, about Instagram, I was mistaken about 'heavy' use. As far as I know there is one guy using Reason in Insta and from what he's said, he's found it pretty straightforward. I don't have a direct link, but if you search for 'instagram' in the ReasonML Discord chat you will find the discussion.
sp33der89 9y ago
How does ReasonML/Bucklescript stack up against F#/Fable. Is the only difference that F# has the .NET environment?
- yawaramin 9y ago
  Good question. I would say the differences are: - BuckleScript targets ES5 (+ES6 modules) directly, while Fable targets ES2015 (and beyond) and relies on Babel to transpile its result to ES5 - BuckleScript/ReasonML needs only NodeJS/npm to work for JavaScript compiles (but you can get the opam compiler/package manager if you want to do native development) - BuckleScript/ReasonML has a more powerful traditional OCaml type system with higher-level abstraction features like functors and generalised algebraic data types, while Fable relies more on OOP for abstraction - At the moment at least, BuckleScript's JS output is far more minimal than Fable's–try defining a simple record type like `type person = {id: int}` in both their online playgrounds to see the difference–it's pretty striking - But Fable does have an open GitHub issue talking about minimising their output to be more BuckleScript-like, so it might catch up - BuckleScript's JavaScript interop is just as powerful if not more, but does require a shift in thinking because its premise is to convert JavaScript idioms into OCaml idioms
  - sp33der89 9y ago
    Thanks for this, great explanation(and as a F# looks fair). I'll try out ReasonML one of these weekends, thank you.
sfilargi 9y ago
A weak point of ReasonML for me, last time I tried it, were the Promises; you have to remember to resolve them, with the compiler not providing any help. It's very easy to miss/forget to resolve them. While it is definitely improvement over JS, it's a step back from the sense of safety you get with TS.
- lilactown 9y ago
  Hey, author here! I definitely agree that Promises - and the whole async story in ReasonML - is pretty poor atm and ripe for improvement in the near future. I'm not sure what you mean by, "remember to resolve them," though? I've helped Wojtek Czekalski out a bit with a small library called vow[1] that provides a more type-safe way of using Promises in BuckleScript/ReasonML - it needs a bit clean up (update to new syntax, publish to npm) that I might do in the coming weeks. Nick Cuthbert has a PR for making it completely sound[2] that might land soon as well, which might change the API but provide even more safety. [1] https://github.com/wokalski/vow/ https://github.com/wokalski/vow/ [2] https://github.com/wokalski/vow/pull/6 https://github.com/wokalski/vow/pull/6
- yawaramin 9y ago
  I would say it's the other way round. In ReasonML, if you forget to resolve a promise, the compiler tells you the types don't match up. This is better and more reliable than the best linting rules you can get today for JavaScript. With TS, to be honest I'm not sure how safe it can be since it must play nice with the JavaScript rules that promises can be automagically resolved.
  - deleted 9y ago
    [deleted]
joobus 9y ago
I like the idea of Reason, but I currently do much more server coding than front end. The native compiler is currently classified as work-in-progress (https://reasonml.github.io/docs/en/native.html https://reasonml.github.io/docs/en/native.html). I also wonder about how the community evolves if javascript-targeted reason libraries aren't compatible with native reason libraries. For instance, would a wrapper for a js promise library be able to work in server code? I'm interested in the language, but currently not investing time in it.
- hurricaneSlider 9y ago
  It's fully compatible with nodejs, so super feasible to do backend dev
  - santoriv 9y ago
    Has anyone actually done this in a real app? The last time I looked for nodejs examples, I could only find small POCs. The vast majority of ReasonML material seems focused on the front-end.
    - lilactown 9y ago
      I ran all of my Advent of Code[0] solutions in Node.js - there's nothing specific really about running a ReasonML app in Node.js vs the browser. Except you don't need a module bundler for the former. :) I've also been slowly working on a small CLI app using ReasonML, ReasonReact and react-blessed. There definitely is a dearth of ReasonML server-side examples, libraries and frameworks, though - especially compared to all the front-end chatter. bs-express[1] is actually quite nice, but hasn't seen much attention from the larger community. I would highly recommend it if it's something you're interested in pursuing. [0]: https://github.com/Lokeh/advent-2017 https://github.com/Lokeh/advent-2017 [1]: https://github.com/reasonml-community/bs-express https://github.com/reasonml-community/bs-express
    - yawaramin 9y ago
      There's definitely activity on the backend, especially with GraphQL, but we don't have any large success stories to report yet. Here's a very cool native-OCaml GraphQL server you can try out today though: https://github.com/andreas/ocaml-graphql-server https://github.com/andreas/ocaml-graphql-server
simplify 9y ago
I've been learning ReasonML for React Native these past few weeks. I love the static typing. I can work on my editor for minutes at a time, and when things compile I see it "just work" on my phone. This is important since reloading a native app is not nearly as fast as reloading a web page. The best part is how FAST the compiler is! It blows me away how fast the reason/ocaml compiler is, considering it spits out JavaScript AND type checks at the same time. Babel, TypeScript, Flow, etc. are all slow as dogs by comparison :)
- girvo 9y ago
  How are you handling navigation?
  - simplify 9y ago
    I haven't gotten that far yet, but I'm planning to use their minimal built-in one: https://reasonml.github.io/reason-react/docs/en/router.html https://reasonml.github.io/reason-react/docs/en/router.html
    - thangngoc89 9y ago
      ReasonReact currently only handle browser routing (it hooks directly into window.location API. So for ReactNative, it could do it the way you used to do with Javascript.
- dahx4Eev 9y ago
  Do you use any third party libs?
Rapzid 9y ago
I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing ecosystem and fantastic server side runtime(node has come a long way, but it's no CLR)?
- chickenfries 9y ago
  I tried getting into F# and for someone not running on Windows without knowledge of the CLR and .NET ecosystem its a hard sell.
  - Rapzid 9y ago
    Was this recently? Things change really fast, within the last year or so we got ionide and core clr support. I've read of people preferring the experience of F# in VSCode these days. Just a few weeks ago I got an F# project with TensorFlowSharp up and running on OSX in VSCode with the ionide extension. It JustWorked™. In any case, I'd suggest you give it a crack again if you are interested. The experience has improved greatly and the tooling seems pretty great now on Linux/OSX. I've been following it for 3-4 years though, so I certainly understand how it would seem like a non-starter in the recent past.
  - honewatson 9y ago
    I found getting F# dev environment set up on Ubuntu was super easy. That said that I found Merlin in Vim to be better than Jetbrains Rider. With Ocaml/Reason you should be able deploy via native binary. The build times and deployment story are going to be similar to Golang on the backend - if it works. With F# you have to deploy the CLR too.
- aaron-lebo 9y ago
  Many devs don't really care for the MS ecosystem. Whether this is old illogical bias or based in reality, IDK, but most of the major tech stacks that that work across ecosystems are further along on the JVM, so people go there.
- swsieber 9y ago
deleted 9y ago
[deleted]
napa15 9y ago
I don't get it, why does nobody ever mention the bad state of the DOM ecosystem in ReasonML? There is apparently a single way of accessing the DOM with a 3rd party library that is nowhere near finished.
bajablast 9y ago
Whoa, I was just looking at some examples of this library and it seriously looks just like JS, only give away is the patten matching(which is a feature I wish JS had)

121 points by based2 9y ago

Nice article! I was also doing Advent Of Code[0] with ReasonML but sadly due to time constraints I didn't get any far. Still learned a lot about ReasonML, even if the solutions weren't really idiosyncratic! Definitely going to dive into ReasonML later again. [0] https://github.com/petetnt/advent-of-code-2017-reasonml https://github.com/petetnt/advent-of-code-2017-reasonml

vemv 9y ago

I'm interested in Reason/Buckle, coming myself from the ClojureScript. The seemingly tinier minified compilation size would be a huge plus. But what are the actual sizes emitted for large scale projects (arguably the ones that matter most for static typing)? Anyone could share real-world experiences? For reference: I know of cases where 60K lines of clojurescript (arguably equivalent to 150K lines JS) compile down to 5MB under advanced optimization mode. (in case that scares you: well it's an actually large app. We should do route-based code splitting soon - easy/robust with clojurescript apparently)

dangerbird2 9y ago
One thing bucklescript has going for it is that it plays nicely with the NPM/webpack ecosystem. If you want your bundled code to be optimized and minified like Clojurescript, just use a plugin/loader for webpack or your bundler of choice to run the Closure compiler or a similar javascript optimizer. Despite being more inflexible about tooling, clojurescript is great because of how it generates code specifically to take advantage of Closure's optimizaitons.
lilactown 9y ago
Hey, author here! BuckleScript itself doesn't actually do any sort of bundling or minification of the code - in fact, it prides itself in generating "human readable" code that, worst comes to worst, one could modify by hand and not be too hung out to dry. So in that case, you are at the mercy of the general JS ecosystem when it comes to module bundling, minification, code splitting, etc. The Google Closure compiler does a lot of the magic behind ClojureScript's advanced optimizations, so theoretically one could leverage those same optimizations with an app compiled by BuckleScript. Unfortunately, I don't have any real-world experiences with this. However, I do have experience using ClojureScript + Google Closure compiler and can give you a heads up that you might (...probably will) run into issues using Closure compiler with NPM libraries, which the BuckleScript ecosystem relies on. As someone who recently started working daily with ClojureScript, I'm really crossing my fingers for some of rough edges around Node.js/ES module support in the Closure compiler to be smoothed out soon! NINJA edit: I have heard good things about rollup with regards to dead-code elimination and other optimizations, but the JS module bundling story is moving at break-neck speed these days and I'm not really keeping up with it - Parcel's a new thing? Jaredly's writing a bundler in ReasonML?? X_X
yawaramin 9y ago
That's a very interesting question. We could ask some Messenger and Instagram people, since they are heavily using BuckleScript. In general output JS is already fairly spartan, because BuckleScript uses a few tricks here and there, like encoding modules and records as arrays instead of objects; and completely inlining functions whenever it can. BuckleScript also emits ES6 modules, with imports and exports, and it marks its output as either pure or impure at the module level. So potentially there's a lot of room for bundlers to do tree-shaking. Bob Zhang, the BuckleScript team lead, is working on a new typesafe standard library for BuckleScript, which takes advantage of compile-time checks to compile to extremely minimal and idiomatic JS. Exciting times up ahead!
- Hurtak 9y ago
  I have heard about the Messenger where they have 25-50% of the web client codebase in Reason, but I have not heard about the Instagram story. Can you share more info or some links about that?
  - yawaramin 9y ago
    Hi, about Instagram, I was mistaken about 'heavy' use. As far as I know there is one guy using Reason in Insta and from what he's said, he's found it pretty straightforward. I don't have a direct link, but if you search for 'instagram' in the ReasonML Discord chat you will find the discussion.

sp33der89 9y ago

How does ReasonML/Bucklescript stack up against F#/Fable. Is the only difference that F# has the .NET environment?

yawaramin 9y ago
Good question. I would say the differences are: - BuckleScript targets ES5 (+ES6 modules) directly, while Fable targets ES2015 (and beyond) and relies on Babel to transpile its result to ES5 - BuckleScript/ReasonML needs only NodeJS/npm to work for JavaScript compiles (but you can get the opam compiler/package manager if you want to do native development) - BuckleScript/ReasonML has a more powerful traditional OCaml type system with higher-level abstraction features like functors and generalised algebraic data types, while Fable relies more on OOP for abstraction - At the moment at least, BuckleScript's JS output is far more minimal than Fable's–try defining a simple record type like `type person = {id: int}` in both their online playgrounds to see the difference–it's pretty striking - But Fable does have an open GitHub issue talking about minimising their output to be more BuckleScript-like, so it might catch up - BuckleScript's JavaScript interop is just as powerful if not more, but does require a shift in thinking because its premise is to convert JavaScript idioms into OCaml idioms
- sp33der89 9y ago
  Thanks for this, great explanation(and as a F# looks fair). I'll try out ReasonML one of these weekends, thank you.

sfilargi 9y ago

A weak point of ReasonML for me, last time I tried it, were the Promises; you have to remember to resolve them, with the compiler not providing any help. It's very easy to miss/forget to resolve them. While it is definitely improvement over JS, it's a step back from the sense of safety you get with TS.

lilactown 9y ago
Hey, author here! I definitely agree that Promises - and the whole async story in ReasonML - is pretty poor atm and ripe for improvement in the near future. I'm not sure what you mean by, "remember to resolve them," though? I've helped Wojtek Czekalski out a bit with a small library called vow[1] that provides a more type-safe way of using Promises in BuckleScript/ReasonML - it needs a bit clean up (update to new syntax, publish to npm) that I might do in the coming weeks. Nick Cuthbert has a PR for making it completely sound[2] that might land soon as well, which might change the API but provide even more safety. [1] https://github.com/wokalski/vow/ https://github.com/wokalski/vow/ [2] https://github.com/wokalski/vow/pull/6 https://github.com/wokalski/vow/pull/6
yawaramin 9y ago
I would say it's the other way round. In ReasonML, if you forget to resolve a promise, the compiler tells you the types don't match up. This is better and more reliable than the best linting rules you can get today for JavaScript. With TS, to be honest I'm not sure how safe it can be since it must play nice with the JavaScript rules that promises can be automagically resolved.
- deleted 9y ago
  [deleted]

joobus 9y ago

I like the idea of Reason, but I currently do much more server coding than front end. The native compiler is currently classified as work-in-progress (https://reasonml.github.io/docs/en/native.html https://reasonml.github.io/docs/en/native.html). I also wonder about how the community evolves if javascript-targeted reason libraries aren't compatible with native reason libraries. For instance, would a wrapper for a js promise library be able to work in server code? I'm interested in the language, but currently not investing time in it.

hurricaneSlider 9y ago
It's fully compatible with nodejs, so super feasible to do backend dev
- santoriv 9y ago
  Has anyone actually done this in a real app? The last time I looked for nodejs examples, I could only find small POCs. The vast majority of ReasonML material seems focused on the front-end.
  - lilactown 9y ago
    I ran all of my Advent of Code[0] solutions in Node.js - there's nothing specific really about running a ReasonML app in Node.js vs the browser. Except you don't need a module bundler for the former. :) I've also been slowly working on a small CLI app using ReasonML, ReasonReact and react-blessed. There definitely is a dearth of ReasonML server-side examples, libraries and frameworks, though - especially compared to all the front-end chatter. bs-express[1] is actually quite nice, but hasn't seen much attention from the larger community. I would highly recommend it if it's something you're interested in pursuing. [0]: https://github.com/Lokeh/advent-2017 https://github.com/Lokeh/advent-2017 [1]: https://github.com/reasonml-community/bs-express https://github.com/reasonml-community/bs-express
  - yawaramin 9y ago
    There's definitely activity on the backend, especially with GraphQL, but we don't have any large success stories to report yet. Here's a very cool native-OCaml GraphQL server you can try out today though: https://github.com/andreas/ocaml-graphql-server https://github.com/andreas/ocaml-graphql-server

simplify 9y ago

I've been learning ReasonML for React Native these past few weeks. I love the static typing. I can work on my editor for minutes at a time, and when things compile I see it "just work" on my phone. This is important since reloading a native app is not nearly as fast as reloading a web page. The best part is how FAST the compiler is! It blows me away how fast the reason/ocaml compiler is, considering it spits out JavaScript AND type checks at the same time. Babel, TypeScript, Flow, etc. are all slow as dogs by comparison :)

girvo 9y ago
How are you handling navigation?
- simplify 9y ago
  I haven't gotten that far yet, but I'm planning to use their minimal built-in one: https://reasonml.github.io/reason-react/docs/en/router.html https://reasonml.github.io/reason-react/docs/en/router.html
  - thangngoc89 9y ago
    ReasonReact currently only handle browser routing (it hooks directly into window.location API. So for ReactNative, it could do it the way you used to do with Javascript.
dahx4Eev 9y ago
Do you use any third party libs?

Rapzid 9y ago

I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing ecosystem and fantastic server side runtime(node has come a long way, but it's no CLR)?

chickenfries 9y ago
I tried getting into F# and for someone not running on Windows without knowledge of the CLR and .NET ecosystem its a hard sell.
- Rapzid 9y ago
  Was this recently? Things change really fast, within the last year or so we got ionide and core clr support. I've read of people preferring the experience of F# in VSCode these days. Just a few weeks ago I got an F# project with TensorFlowSharp up and running on OSX in VSCode with the ionide extension. It JustWorked™. In any case, I'd suggest you give it a crack again if you are interested. The experience has improved greatly and the tooling seems pretty great now on Linux/OSX. I've been following it for 3-4 years though, so I certainly understand how it would seem like a non-starter in the recent past.
- honewatson 9y ago
  I found getting F# dev environment set up on Ubuntu was super easy. That said that I found Merlin in Vim to be better than Jetbrains Rider. With Ocaml/Reason you should be able deploy via native binary. The build times and deployment story are going to be similar to Golang on the backend - if it works. With F# you have to deploy the CLR too.
aaron-lebo 9y ago
Many devs don't really care for the MS ecosystem. Whether this is old illogical bias or based in reality, IDK, but most of the major tech stacks that that work across ecosystems are further along on the JVM, so people go there.
swsieber 9y ago

deleted 9y ago

[deleted]

napa15 9y ago

I don't get it, why does nobody ever mention the bad state of the DOM ecosystem in ReasonML? There is apparently a single way of accessing the DOM with a 3rd party library that is nowhere near finished.

bajablast 9y ago

Whoa, I was just looking at some examples of this library and it seriously looks just like JS, only give away is the patten matching(which is a feature I wish JS had)