Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

25 Days of ReasonML

medium.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: 25 Days of ReasonML

#11

Post by yawaramin »

vemv wrote: post #2

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…

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!

Re: 25 Days of ReasonML

#12

Post by yawaramin »

sp33der89 wrote: post #4

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

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

Re: 25 Days of ReasonML

#13

Post by yawaramin »

sfilargi wrote: post #5

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.

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.

Re: 25 Days of ReasonML

#14

Post by simplify »

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 :)

Re: 25 Days of ReasonML

#15

Post by Rapzid »

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

Re: 25 Days of ReasonML

#16

Post by lilactown »

joobus wrote: post #9

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 ). 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 cod…

There are definitely individuals exploring the native-compilation story, for instance bsb-native[0] allows BuckleScript to use OCaml's native compilation tools. Jared Forsyth has also been publishing a lot of material[1] about creating cross-platform project using ReasonML.

The ReasonML team seem to be taking a conservative approach towards what they officially release. They want to make sure that they have a really good plan on how and where to move forward with each of these stories - async, native compilation, cross-platform project, optimizations, etc. Right now they seem to be focusing on creating a really high quality platform for building front-end web applications, but all of these things are on their mind.

I'm actually reminded of the fact that Jordan Walke (initial creator of React) is currently working on a native OCaml/Reason package manager called esy[2], which in my mind is kind of the starting point of the native compilation story: unifying the package and build system of the two ecosystems.

[0]: https://github.com/bsansouci/bsb-native

[1]: https://jaredforsyth.com/

[2]: https://github.com/esy/esy

Re: 25 Days of ReasonML

#17

Post by santoriv »

hurricaneSlider wrote: post #10
joobus wrote: post #9

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 ). 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 cod…

It's fully compatible with nodejs, so super feasible to do backend dev

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.

Re: 25 Days of ReasonML

#18

Post by chickenfries »

Rapzid wrote: post #15

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

I tried getting into F# and for someone not running on Windows without knowledge of the CLR and .NET ecosystem its a hard sell.

Re: 25 Days of ReasonML

#19

Post by sp33der89 »

yawaramin wrote: post #12
sp33der89 wrote: post #4

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

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…

Thanks for this, great explanation(and as a F# looks fair). I'll try out ReasonML one of these weekends, thank you.

Re: 25 Days of ReasonML

#20

Post by Rapzid »

chickenfries wrote: post #18
Rapzid wrote: post #15

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

I tried getting into F# and for someone not running on Windows without knowledge of the CLR and .NET ecosystem its a hard sell.

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.

Post reply on HN