Live data from Hacker News

Exploring ReasonML and functional programming

reasonmlhub.com

31–40 of 65 posts

Re: Exploring ReasonML and functional programming

#31
post #17

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

ReasonML has a much more advanced module system via Functors. As far as I know Elm has nothing like this. Despite a fair few arguments over incorporating type classes into Elm, the creator is pretty dead set against the idea. This does make Elm a lot more approachable, but after a while can feel quite restrictive. There is bucklescript-tea, which is the Elm architecture in for Bucklescript (and thus also Reason). It…

> Elm community is more mature which means there is more documentation and libraries available

There's some excellent libraries but the Elm documentation is terrible compared to Reason.

Re: Exploring ReasonML and functional programming

#32

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

> why I might pick ReasonML over Elm for front-end development?

I think ReasonML is better compared to TypeScript and Flow, rather than Elm.

Elm is pure, but I would still want to write my JS ports in a statically typed language. I would use TypeScript, but here is the project that let you use ReasonML[1]

[1] https://github.com/jaredramirez/reason-elm

Re: Exploring ReasonML and functional programming

#33
post #21
post #3

Why should someone unfamiliar with functional style programming be learning ReasonML rather than say, something like, haskell? Looking for concrete, technical answers.

I view this as more of a general, why should somebody learn Ocaml instead of Haskell? There's a couple of reasons. #1. Ocaml's type system is nearly as expressive as Haskell's and includes several features that Haskell's does not. Polymorphic variants and functors being notable ones. #2. Laziness is very hard to get right in practice. I'm sure Haskell enthusiasts will not be very happy with that statement, but I thin…

I wrote this on my phone a couple hours ago, and I wanted to add a couple qualifiers that might be misleading to people.

Laziness being hard to deal with isn't the only reason Standard Chartered uses their own compiler that's strict by default. However, they have noted that they do think strict haskell is a lot easier to deal with.

Re: Exploring ReasonML and functional programming

#34

Earlier quoted context omitted.

You wouldn't choose it over haskell every time, but for the limited subset of times where you need to write frontend code ReasonML has distinct advantages. ReasonML is basically OCaml that compiles to JS, designed to make interoperation with Javasascript easy. There are compile to JS projects for Haskell too, but the ease of interoperability with popular JS libraries like react and support from facebook's open source…

That's not correct. What you've described is Bucklescript (which has OCaml syntax). ReasonML is an attempt to "improve" the OCaml syntax to something more familiar to folks coming from C-style family of lanauges. ReasonML can be used with both the Bucklescript compiler (which compiles to JS) -or- the standard OCaml one (which compiles to native).

While that is technically true, most people nowadays use them interchangeably especially because Reason is focusing so much on its web story, so I wouldn't expect people to make this distinction very often.

Re: Exploring ReasonML and functional programming

#35
post #3

Why should someone unfamiliar with functional style programming be learning ReasonML rather than say, something like, haskell? Looking for concrete, technical answers.

Because Reason fully supports imperative and OOP style. You don't need to use functional style if you don't want to (of course, aside from using other people's code). Here's some classic OOP:

    class animal = {pub speak = "Animal noise";};
    class cat = {inherit class animal; pub speak = "Meow!";};
    class dog = {inherit class animal; pub speak = "Bark!";};

    let speakTwice(animal: animal) = animal#speak ++ ", " ++ animal#speak;
    print_endline(speakTwice(new dog)); /* Bark!, Bark! */

Re: Exploring ReasonML and functional programming

#36

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

> Someone will have to explain why I might pick ReasonML over Elm

* bigger team (Elm the lang itself is almost a one man show)

* openly developed (Elm's dev't is in private, for now at least)

* interop with JS is easier

* great interop with React

* has a company behind it (FB), who uses it in production (messenger.com)

* already works on the server (with Node and with experimental native compilation (bsb-native))

* server-side native compilation is within the vision the core team (not so much with Elm)

* a lib exists for The Elm Architecture (TEA), see the bucklescript-tea package

* JS'ish (C'ish) syntax (Elm has an ML like syntax) -- this may or may not be your thing, I think it makes FP more accessible

* not pure functional (like Elm), thus allows mutation and side effects -- this may or may not be your thing, it makes interop with JS easier but comes with less strong safety guarantees

> Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible.

Elm's community is great, but probably smaller than ReasonML's community in the long run, as I expect FB to use it a lot internally and thus has a great patron. Also, most big tech has their own language: Apple/Swift(ObjC), Google/Go(Dart), Mozilla/Rust, FB/Reason. I think it is the only language that potentially facilitate both FE, mobile and server-side dev't. It's a very interesting pick at this point.

> ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

Yes. And to me this does not sound bad. They took OCaml, and BuckleScript, then added a new syntax, some tooling and libraries. They positioned a language that ticks a lot of boxes in a very short time, and since it has free interop with OCaml it comes with quite a strong lib ecosys for native (server-side) dev't.

Re: Exploring ReasonML and functional programming

#37
post #4

FYI for anyone who was fuzzy on the license/patent situation with the project: https://github.com/facebook/reason/commit/e8fb73ec6ff7c31367... (As of 12/2017, relicensed to straight MIT from BSD+patent.) Rauschmayer's work here makes me interested in the language and motivated to learn it. After reading more, only wish I'd explored for a recent project where I was working to implement a lot of functional patterns in…

Someone can correct me, but Reason is just a syntax on top of Ocaml's compiler. Bucklescript and Reason even share the same site design. there's not much of a choice beyond what you like more, as they use the same libraries, tools, etc. Does anyone know where this new wave of interest came from?

Community. The Reason team focused on building it, and neatly embraced and nurtured BuckleScript in the process. It's a symbiotic relationship and the community has a reputation for being very newbie-friendly to boot.

Re: Exploring ReasonML and functional programming

#38
post #27

I'm looking for a language for cross-platform mobile app development using React/Expo. Can anyone give their opinion on ReasonReact vs Clojurescript Reframe? I like the familiar syntax of ReasonML, but Clojurescript has LISP mojo and is more mature (more learning resources etc).

I don't know what the status of ClojureScript Reframe is, but there is an unofficial, in-progress ReasomML binding to Expo. You can contribute to that if you want https://github.com/fxfactorial/bs-expo (note that @fxfactorial, i.e. Edgar, works at Expo but is writing the Reason binding unofficially–for now at least).

The ReasonReact binding is high-quality and provides a lot of power (state management, routing) right out of the box. You can get started with that right now if you wish.

Re: Exploring ReasonML and functional programming

#40

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

I would also like to know if ReasonML makes some "guarantees" of zero runtime errors like Elm does. That's one reason what makes Elm attractive to me, though I haven't programmed much in it.
Post reply on HN