Exploring ReasonML and functional programming
reasonmlhub.com
reasonmlhub.com
Hello world in ReasonML will get you a single line javascript output. Last I looked, the Elm bundle is in the 10s of kbs for something like that because you get the whole architecture.
Add is ReasonReact and it's a little more comparable obviously.
Elm is just "Elm"... that isn't a bad thing and it seems like it is more mature at the moment.
ReasonML is Ocaml that plays nice on any screen anywhere thanks to Bucklescript. It also plays nice as a systems language. That is, unikernels... I am not even sure what they are, but they sound awesome and I want that.
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 is pretty much an exact match, so technically there isn't really anything you are missing out on by going with Reason. In reality the Elm community is more mature which means there is more documentation and libraries available. However bucklescript does interface to javascript a LOT easier - which does open up a much wider ecosystem of javascript libraries.
There's some excellent libraries but the Elm documentation is terrible compared to Reason.
The only way I see this changing is if Evan massively delegates responsibility, and I just don't see that happening. Elm is cool because it's small and tightly controlled, but that also limits its viability and growth potential.
Even just Dr Rauschmayer's blog and now this book blow away anything I've ever found in the Elm ecosystem.
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]
* 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.
ReasonML's documentation also seems better (especially for a functional programming newbie)
There's also core_kernel, which is core but without the libc support.
(Of course I'm biased too, I wrote containers ^^)
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 native JS.
Any thoughts about ReasonML vs "straight" OCaml? (Or does that question even make sense?)
Does anyone know where this new wave of interest came from?
I've heard of (and from) web developers who say that they find OCaml impossible to read, but that ReasonML is easy and pleasant for them. So part of this is what you are used to, and another is subjective preference.
There are other conveniences as well, including the fact that Reason comes with a tool (refmt) that can autoformat your code to a standard style, wiping out style guide arguments etc.
Love his stuff!
Now async/await and Reason is good to go ;)
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 tooling chain make it a much better choice for most frontend projects IMHO -- unless you're already a haskell expert in which case go with what you already know!
It just cost me so much time to constantly think about IO that I was barely figuring out what I wanted to write. It seemed impractical to me and now with some more experience I still think it is. Ocaml type languages strike a better balance in my opinion if you're interacting with the world.
For someone new to the Typed FP world though, Reason or Elm would be an easier starting point. Both communities are geared towards newcomers and have first-class support for front-end development.
My brief foray into Elm was very pleasant, and it is a community with great taste and aesthetics. Evan Czaplicki is wise beyond his age and is building a language that will last a long time. One reason why I would reach for ReasonML than Elm however is Reason's zero-overhead interop with Javascript. You can do this right in the middle of your code `[%%bs.raw console.log ("hey")];` and nobody will complain. This interop allows Reason to utilize the vast NPM ecosystem - so you can gradually adopt Reason in your front-end codebase. Your ReactReason code can use your plain React components and vice versa, and you can even use the bs-express library to write NodeJS applications with ExpressJS.
Elm aims to remain pure because it allows them to build a more solid ecosystem in the long run. It is a great choice as well, just that the shorter-term trade-offs make it slightly more difficult to work with existing Javascript code.
One angle in which Reason would be a better beginner language than Haskell is the number of concepts you have to understand before you can be truly productive with it. The shift from an imperative, dynamic world to a functional, statically typed world is already difficult enough. Reason/OCaml makes this transition easier because with it you can program in the familiar imperative style when you want, unlike Haskell where you need to rely on the elegant but takes-some-effort-to-grok Monads to tackle the Awkward Squad of I/O (https://www.microsoft.com/en-us/research/wp-content/uploads/...). And this might be controversial opinion - but the historical roots of Haskell as a language for bleeding-edge academic experimentation has lead to a certain kind of fragmentation that demands more effort from newcomers than a made-for-industry language would need. PureScript and Idris however have standardized on many of these things and might not share the same concerns. You still have to content with its laziness and purity. These are both practical and aesthetic choice in how to program, and they are very fun to explore. You just need to get started on some language in the statically typed FP camp to appreciate this long, deep rabbithole!
Plus ReasonML isn't strictly functional. You can have side effects and mutation if you need. Obviously the purists may view this as a negative, but being able to eg. just get a random number without going through a ton of hoops can make things a bit less frustrating - especially if you are unfamiliar with functional.
Once you have a good grasp of functional through ReasonML, Haskell will feel a lot less daunting.
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 think it's true. It's the reason why one of the biggest users of Haskell (and the most notable example of Haskell in industry), Standard Chartered, uses their own Haskell compiler that's strict by default.
#3. Less productive in practice. For example, long build times are a huge problem in practice. See https://www.reddit.com/r/haskell/comments/45q90s/is_anything...
for comments from the Haskell community, including GHC maintainers.
Really though, I don't think you can really go that wrong with either. Transferring from each language to the other one isn't very difficult, and they're both excellent languages.
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.
That's news to me. Where did they note that? Lennart Augustsson explicitly says "I don't think strict or lazy matters that much in practice; they both work fine".
http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...
http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf
> Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased difficulty of modular composition
FWIW, I am a bit jealous of how laziness makes it easier to achieve function composition, and that was something that I wish was easier in strict semantics.
https://www.youtube.com/watch?v=hgOzYZDrXL0
> So strictness is really fantastic, I must say. Stack traces work. When something goes wrong, you can say "so you call things from there to there to there". It's the single most time saving thing from Mu compared to Haskell, because things do go wrong from now and then, and it's so great to know exactly what went wrong... And strict languages have what I call resource composition. So if you understand the complexity of 2 parts you can stick them together and nothing weird happens. They add up. That's not true in lazy languages. And debugging, it's sensible in strict languages. And exceptions, they actually work! Strictness is great. It's terrible, also. So it has nice resource composition but it doesn't compose nicely semantically. So laziness has some good things as well. I think laziness is a much nicer way of programming except for these pesky resources. You definitely need some lazy functions, even C has lazy functions.
And then he goes on to talk about the ways that they allow laziness in a strict language, and when they need laziness.
Screenshots of relevant slides. Considering that the report was pretty much a summary of the talks given at CUFP, I don't know why you would cast doubt on its legitimacy.
1. It is incorrect to claim that "Laziness is very hard to get right in practice. ... It's the reason why ... Standard Chartered, uses their own Haskell compiler that's strict by default."
2. Rather, the reason Mu is strict is that it was designed to target an existing strict runtime (I offer this claim without proof but I was told this directly by one of the authors of Mu).
3. It is incorrect to claim that Standard Chartered "think strict haskell is a lot easier to deal with"
4. Rather, Lennart Augustsson holds that each has their upsides and downsides. He says "I don't think strict or lazy matters that much in practice; they both work fine" and "I think laziness is a much nicer way of programming except for these pesky resources."
> If my only concern was semantics (i.e., input-output behavior) then I'd prefer call-by-name semantics, because I think it behaves more compositionally. But for practical concerns like resource consumption, debugging, stack trace, etc then strict evaluation is better.
Overall though, you're right that my initial claims against strictness may have been a bit too harsh. If I could edit my initial comment, I would write something more like
> 2. Laziness is often hard to use in practice. As Standard Chartered, a company that uses a strict variant of Haskell, notes: space leaks, difficulty of debugging, and hard to decipher stack traces are downsides to laziness.
In my opinion, laziness definitely does have nicer semantics than strictness. It's more expressive and easier to compose. In practice though, I prefer strict languages mostly for the reasons Standard Chartered mentions.
No it's not. The reason Mu is strict is that it was designed to target an existing strict runtime.
For those who don't know, ML-style modules are significantly more interesting than most module systems, and let you pass modules as arguments to modules at import.
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! */I like the familiar syntax of ReasonML, but Clojurescript has LISP mojo and is more mature (more learning resources etc).
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.
My team recently weighed Clojure(Script) & ReasonML and chose Clojure, because we need to ship and it's not going anywhere.