Elm vs. ReasonML

[nelsonic]

@nielsbom shared a bunch of links to discussions of Elm vs. ReasonML in dwyl/learn-elm#129 (comment)

⚠️ Warning: if you're already "sold" on using ReasonML for whatever reason, this thread is not for you.
This thread is to capture our reasoning for preferring to use Elm despite the heavy marketing from Facebook fanboys (& girls) who have a vested interest in perpetuating Facebooks technology.

Each person should make up their own mind on what technology they want to use for their own projects based on the requirements and their own preferences for "more features" vs. simplicity and risk/reward.
Sadly, Facebook does not "play fair" in any field.

Why Choose The Language with Fewer Features?

People often make decisions based on feature comparisons and seldom make a choice based on the absence of a feature. It's a curse that many people in our generation are afflicted with; always thinking that "more is more" when in fact more is often less. This is the "official dogma" described in
Psychologist Barry Schwartz' book "The Paradox of Choice – Why More Is Less"
https://en.wikipedia.org/wiki/The_Paradox_of_Choice Summarised in his hugely popular Ted Talk: https://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice

People don't often consciously make the decision to chose the thing that has fewer features,
when they are discussing (rationalising) a choice but we subconsciously do it all-the-time!
https://en.wikipedia.org/wiki/Choice-supportive_bias

One of the things I most admire about Elm is something most people don't realise is even a thing!
Evan has an incredible focus on what he is trying to achieve, he's trying to reduce the number of features in the language to the minimum needed to build a complete system. Reducing the complexity while still allowing people to build complete applications is a skill few programmers have mastered.

The concept of saying no to a feature is alien to many people who think that having more features is always better than fewer.

By allowing "JavaScript snippets", ReasonML opens the floodgates to all the "features"

But it creates a maintenance nightmare because now there are no more type-safety guarantees!

There is an often overlooked fact when discussing ReasonML and Elm in the same sentence.
ReasonML is Facebook's effort to re-invent/rebrand ML https://en.wikipedia.org/wiki/ML_(programming_language) so they can own it.
In much the same way that Facebook attempted to re-invent Node.js package management with Yarn
instead of making the upstream improvements to NPM (which is open source but they do not own),
i.e. Facebook systematically fragments Open Source to their own benefit by re-implementing languages/libraries that are already popular.

Facebook is the bully that copies your homework after you spent ages working on it,
and then takes the credit for "inventing" it ... they do this all-the-time!
https://www.wired.com/story/copycat-how-facebook-tried-to-squash-snapchat
https://hbr.org/2017/05/can-snapchat-survive-if-facebook-copies-all-its-best-features

The initial commit for ReasonML reasonml/reason@1037c7d was on 20 Feb 2016, years after other Open Source compile-to-JS ML implementations (including Elm) had been released and gained traction. This is relevant because instead of contributing to Elm, Facebook chose to re-implement/re-package (copy) many of its' best features. And then by adding a few extra features that some people feel they need, ReasonML looks like a "better" alternative when compared purely on a "features basis".

"If you take two products and compare them on feature-checklists that gets you
a very inaccurate picture of what it's going to be like to actually use them."
6 Months of Elm in Production by Richard Feldman

One of the often cited key differences between ReasonML and Elm is how JavaScript (and OCaml) inter-operation ("interop") works. ReasonML lets people use packages directly from NPM or "drop in a snippet of raw JavaScript" which makes it far easier to break guarantees of the the Type system.

Elm's approach to interop is that JS should not be invoked directly, but rather "messages" should be passed between trusted and delegated (or "untrusted") systems. This is a far more sane and secure way of doing interop which some people find "too restrictive" but others realise is liberating because it means Type-safety is still guaranteed. i.e. we can use JavaScript with Elm but it won't "break" the Elm!

Not saying people shouldn't use ReasonML, just that they should be aware of the context and realise that it's an imitation of Elm which is superficially similar but really not comparable in overall user (developer) experience when in Production. ReasonML cannot guarantee "no runtime errors" in practice because it allows "JavaScript snippets" ...

“Imitation is the sincerest form of flattery that mediocrity can pay to greatness.” ~ Oscar Wilde

Sometimes the replica is so (superficially) good that it's difficult to spot the differences ...

Sadly, most people don't know (or care) about the differences. (see: https://youtu.be/P_ZTqC2Yxxs )
But if someone offered you a choice of a free one, which one would you pick?
The one that does the job flawlessly and will continue working reliably for your lifetime
or the one that will "break" because it's "internals" are compromised?

ReasonML and Elm are similar in the same way that a replica iPhone is similar (in appearance) to an original Apple iPhone. The "spec sheet" might sound impressive and the outside "looks the same" ... it's close until you actually attempt to use it.

If it's a question of "price" sure, you would consider the "GooPhone" goophoneshops.com/100050

But imagine if iPhone hardware was free and all the software was Open Source ... would anyone want to use the "GooPhone" (clone) with a worse camera, screen and spyware OS?

build error on master branch ... 🙄 (not something you would build a mission critical system with...)

Also, why does it take 3 hours to run the build...?! Who has that kind of time...? ⏳

I don't like "picking" on other people's code/projects because it's "throwing stones" ... 😞
But there is so much propaganda from Facebook (Fake News Network) that it's difficult to tell the noise from the facts. ReasonML is "good" if you work at Facebook (and cannot use Elm because of internal politics and "not invented here" syndrome), but for everyone else, it's a distraction.

[nielsbom]

Thanks for the big write-up! I've been mulling all of it over for a couple of days and I'd like to dissect it in a couple of points.

Bad organisations can produce useful stuff

Personally I feel Facebook has a net negative effect on the world. That being said, I don't think everything that Facebook produces or the people that work for Facebook create is bad. When talking about open source technology, I don't think it's necessary to disregard a technology solely because the organisation pushing it is doing things that are morally reprehensible. I think React has had a big positive influence on frontend web development for the last few years, also by promoting the reactive programming style. Microsoft for example has done some stuff that was definitely reprehensible, but recently they've been doing good work in open source with VSCode.

Working with "their" tech and contributing to it will probably help them in some ways. The question then becomes: is it moral to do so? are you comfortable doing this?

I think it's good (from a personal and a business perspective) to look at non-technical properties when comparing technologies, so the motivation behind or atmosphere around a technology is definitely important. I think people being worried about Evan's "bus-factor" is in the same category.

Facebook re-branding technology (as their own)

When anyone passes of something that they didn't make as their own: not cool.

Facebook systematically fragments Open Source to their own benefit by re-implementing languages/libraries that are already popular.

But, license-issues notwithstanding, forking and changing stuff, slapping a different name on it (for whatever reason), that's basically how open source works right? If we look at the ratio of total value/total effort I'd think the optimum is somewhere between "lots of forks" and "only one solution". I agree to a large degree that Facebook could give more back to the world via open source by contributing to existing projects versus forking, but if they choose not to that's just their choice and not inherently evil I'd say.

Choosing a language with fewer features

Great, valid points here! I especially like the psychology-part of it, which is highly relevant.

The way Elm interfaces with JavaScript libraries (which I don't have experience with) sounds cleaner and more reliable than how ReasonML does it.

Elm and ReasonML look the same from the outside (and marketing)

The whole real vs fake argument, I don't really get what you're saying there.. 🤔

Are you saying something like "Because FB is better at marketing people will choose the inferior technology"? That's definitely possible, we have numerous examples of that.

How to win that war for Elm? I think you're doing great work to increase those odds :-)