I tried Reason out maybe half a year ago. To me, the exceptional thing which the Reason project lacks is a polished developer experience. It feels very much like a hacked together combination of technologies which requires the developer to install several things just to get a working compiler.
I think before I would try Reason again there would need to be some effort put into streamlining setup and managing of the developer environment.
EDIT: Downvoted? Let's hear some feedback and other opinions maybe?
There has been a lot of work in making the developer experience as awesome as possible. I know that, for the core team, it is one of the highest priorities.
At this stage, the only thing you need to do to get Reason to 'work' is to use Create Reason React App (when targeting the browser).
The language/compiler itself is installed as an npm package(!). The only other things to install are the CLI tools (again, just an 'npm install' away) and optionally a plugin for your editor.
This, not unlike Elm, looks pristine, ivory-tower-ish to me. The examples are always neatly self-contained or consuming a real simple json API. They're fiddles. Fiddles always look neat.
I think it would do these types of projects a lot of good to do something real using third party libraries. Convince developers and companies they're real, not toys. I still haven't seen a blog post explaining Elm along with a masonry library, socket.io, bootstrap, shopify, etc.
Probably I'm not getting what's the real use case for these things. It can't be writing web apps.
I don't think Reason is like Elm in this way. Whereas Elm requires you to wholly buy in to the Elm world, Reason can easily be brought into a large existing codebase.
Large chunks of messenger.com are written in Reason. I'm pretty sure that qualifies as a 'web app'.
We're already using immutable values in Javascript thanks to React. This takes the form of manually cloning objects before mutating them, or using immutable-helpers, or immutable.js. This lets us reason about the data flow easily, and more importantly, allows React's shouldComponentUpdate do dirty check using fast reference equality.
Functional programming - in FP languages, all functions are curried by default. So you don't need the awkward `bind` function to use it. Add extremely light weight function definition syntax and tail-call optimizations, and we have a language with first-class functions.
Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. ReasonML is OCaml, and it has a very powerful and sound type system.
Since Immutability, functional programming, and Hindley-Milner type systems are becoming ever more necessary to build complex front-ends, it makes a lot of sense to simply use a language that was designed for it. OCaml in its current form has been around for more than 20 years, and the research and other languages that influenced, is even older. It is a fun beautiful language that lets you focus on the shape and structure of your data front and center.
I'd only add a mention of algebraic data types. I learned enough Elm and Haskell to realize the benefit that they bring to a codebase by allowing an expressive way to define the valid structure of an application's data and state.
I was told that concurrency primitives can be built on top of algebraic data types, so I intend to learn more. I was also told that ReasonML does not yet support algebraic data types. What am I missing?
Oh yes. Thank you for the correction. The fancy name has kept me away so far... fearing it's yet another monad thing which I have not seen explained in a way that not only makes sense to a 5 year old but far more importantly show clearly and indelibly why it's so important to begin with. Same for any 'math theory' derived concepts. I hope ReasonML won't fall in that 'too smart for the average guy' category.
the question I had asked that brought up 'algebraic effects' was: does ReasonML have optimized generator implementation which is an essential high level concurrency primitive. I was told generators and other concurrency primitives can be built on top of algebraic effects.
Btw the ReasonML you're talking about is still just a syntax transform; you're really asking whether OCaml/BuckleScript has these implementations. There's no generators; but I do believe they can be built on top of algebraic effects.
Regarding jargons: you don't have to worry about that =). Though I think what's more crucial is the way the jargons are conveyed, rather than the meanings themselves. I work in the ReactJS community, and there's basically as many jargons (some of which I myself don't quite understand...) as in FP, yet people seem fine with them. We're still not gonna go "monad this monad that" like you feared. Though if the JS community starts picking up terms like monads in the future thanks to Reason, then all the better.
Yeah, it's just funny how the JavaScript community is all jumping on the types bandwagon right now and acting like it's some new discovery or something.
It's possible for someone to be an expert in both JavaScript and OCaml. Or any language. The JavaScript language is both approachable and in wide use, attracting not only novices, but experts from many domains.
It seems silly to assume the "JavaScript community" is no more than its lowest common denominator of novice programmers, jumping on bandwagons without any historical context. People are jumping on bandwagons, sure. But every bandwagon needs a driver, who by necessity must be an expert in multiple domains.
The people pushing these trends are not naive to their historical context. They simply see practical benefits worthy of experimentation, and they don't let emotional attachments to their knowledge cloud their judgment.
Why do you sound aggrieved about it? Types _are_ new for javascript. Until a few years ago there was no way to build for the web using a typed language unless you were using things like GWT or Haxe.
I work on Reason, so I think I'm relatively unbiased enough to address this. JavaScript's widely popular, disregarding why it's come to be this way. Any language this popular (and with a history of being used in a different context, nonetheless) ends up having warts and being used by folks who are sometimes less skilled.
In that regard, "jumping on the types bandwagon like it's some new discovery" is exactly right, because it's indeed lots of people's first language. But I don't see why this should sound so negative. Newcomers are now introduced to types and they're amazed by them. That's welcomed and we shouldn't feel they're taking away our own shiny toy and tainting them or whatever.
I think it pays to be nice to beginners. Sure, you don't get the usual quality you're looking for in a niche expert language where communications are atomic, on-point, and lossless, but that's _OK_. All in all, things like a better type system, better language semantics and better paradigms are still worth fighting for.
* JavaScript will be around for a long time. Our stance is more gradual improvement than world-breaking changes all over the place. I'm still trying to phrase this correctly, because sometimes when Reason gets mentioned, the immediate reaction is "wow they're gonna rewrite everything again, kids...". Our interop story is pretty damn good. Please check it out!
* See ReasonReact's license =)
* The more successful Reason is, the less we'll drink. Kidding
Our discord channel is at discord.gg/reasonml. I think we're a bunch of pragmatic and nice folks. It'll take time for people to understand our stance, but blog posts like these really help showing what we're doing.
If your question is about why one would use Reason, Reason is an interesting alternative to Javascript for building web front ends (though it also can compile to very fast native code for backend/systems use too).
Some things I feel are an improvement over Javascript + Flow or Typescript are:
- immutable data structures built into the language (and more conventionally used)
- real pattern matching on types, 'variant' types (like enums in Rust)
- better dead code elimination (helps to keep browser payload size down)
- you can use expressions everywhere (allowing more flexible code style than Javascript)
- currying/partial evaluation
- under the hood it's really just OCaml, which has benefitted from many years of development and improvement
Static typing and compile-time checking are two very good reasons, same reasons you'd use Elm.
I am not a react developer but I have heard that one of the common complaints about React is ... that it's not Elm, or in more explicit terms, in case you don't know anything about Elm, ... that it's very easy to write code that will break if you poke it the wrong way.
In a static typed language such as Elm (or Reason, based on skimming briefly)... when you get input that can mutate the state of the program, it comes in the form of a message. The messages are typed, so you know what values to expect.
If you write a switch/case statement that handles a message type, the compiler will balk at you if you change the values that the message type can have, without updating the case statements that operate on that type to cover them all.
The tradeoffs between Elm and Reason/Fable are that the former is Pure and the latter have imperative escape hatches. There are benefits to both. Elm has a neat time travelling debugger built in and enforces semantic versioning via their package manager. Reason and Fable have much tighter integration with the javascript ecosystem. This tends to lead to differences in community package philosophy with Elm mostly maintaining its own package repo (own vdom system, own date lib, etc) with the occasional ports for interacting with popular javascript libs while the more nascent Reason/Fable communities tend to write interface definitions and call the JS directly (e.g. they use React for vdom).
I group Reason (Ocaml/Bucklescript) and Fable (F#) together because F# is OCaml's sibling language on .Net. They're very similar. The two projects have similar philosophies, specifically to bring their ML variant to the javascript ecosystem in a module-by-module mixed-language fashion instead of having the language be its own island in the browser. Neither has a particularly large community but the Reason guys have been doing a better marketing push this month, at least from my perspective.
I'm not familiar with the latest ECMA and standards updates and I suppose I don't really know what modern JS actually looks like, but the example on this page[1] doesn't look like syntactically valid JavaScript to me.
If you write code that has to be compiled before it turns into JavaScript, there's another benefit though... it's that you can never accidentally promote code to a server that hasn't already been vetted by the type-checker!
Or, even run it locally! You are guaranteed that the type checker has been run before the code hits a runtime environment.
Looking at Flow, I'm seeing there's a tool `flow` that you run any time you want to check the types. I think there's a background process way to run flow, that mitigates this issue somewhat... but if Flow is in fact implemented to always be syntactically valid JavaScript, that could be a bad thing.
> that it's very easy to write code that will break if you poke it the wrong way
No way. Even in its most basic, untyped form the React model simplifies things all the way down your app pipeline. Errors that used to be common tend to naturally vanish over time.
I need to learn React, I need to learn Elm... I don't really know what I'm talking about, but on the internet nobody knows you're a dog.
We have some fairly sophisticated JavaScript that is part of our app, but we haven't drank any of the modern JS kool-aid yet, the only validation we're really using is a suite of feature tests written with Cucumber and Selenium/Chromedriver.
So if you have some JavaScript and it is functionally important to a feature that you've tested, it will show on the CI result if it's broken... but if there's a JavaScript error during the test that didn't stomp on the behavior tested by the feature, you'd never find out about it unless you happen to be watching the Inspector console at the time.
It's a "dialect" (sort of) of Ocaml, with all of the beauty that is its type system and Functor (not thing.map, parameterized modules!) that can compile to JavaScript via Bucklescript.
If it's ends up being notably superior in multiple ways, and you already have a properly configured and flexible build toolchain in place (i.e. Webpack), adding support should be trivial. I haven't personally used it, but a quick search landed me on the bs-loader [0] repo, which claims to work with both OCaml and Reason files.
As I understand it, and I'm not very familiarized with Reason, the team behind the project is working hard to have a good interop story. We've seen the same thing with React's versioning scheme [1]! Going forward there shouldn't be horrible breaking changes, and in the cases where stuff must be broken, they appear to commit to providing a clear migration path that can be adopted gradually.
There's probably plenty of good use-cases for using something like Reason. Should it be used everywhere? No, certainly not. But having worked on a reasonably sized JavaScript web app, my experience has been that it becomes increasingly difficult to maintain as it grows. Even with something like Flow or TypeScript, you have to think very carefully any changes. Luckily, the JavaScript ecosystem has modularized everything quite heavily, so you can usually contain things that end up being "bad ideas" and gradually chip away at em.
The app I worked on wasn't even that large or complicated, so I have a very hard time wrapping my head around the challenges faced by engineers working on Facebook's scale.
I think before I would try Reason again there would need to be some effort put into streamlining setup and managing of the developer environment.
EDIT: Downvoted? Let's hear some feedback and other opinions maybe?