HN Theater @HNTheaterMonth

I'd highly recommend Jordan Walke's (creator of React) talk on the ideas behind ReasonML: React to the Future [1].

I think it's so cool that you can take the ideas of ReactJS - functional programming applied to UI - but then have a language (ReasonML [2]) that is essentially purpose built for it, with OCaml [3] powering it under the hood - a functional programming language that's been significantly invested in, both in academia and industry. And to be able to take React-the-Idea, compile it cross-platform, to native-code... and ship.

- [1] Jordan Walke - React to the Future: https://www.youtube.com/watch?v=5fG_lyNuEAw

- [2] https://reasonml.github.io/

- [3] https://ocaml.org/

The long awaited 0.8.0 release from Reason React is out of beta! This includes a lot of the niceties of writing React but in a very fast, type safe language.

If this is your first time hearing about Reason, watch a video from its creator (Jordan Walke, creator of React) to learn more:

https://www.youtube.com/watch?v=5fG_lyNuEAw&t=11s

Fun facts about Reason:

- exports TypeScript! If you have a TS project and looking for some extra speed & stability, you don't have to sacrifice type safety interop

- It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason

- It uses the npm / yarn ecosystem so you can use your favorite / current packages without looking for something new.

⬐ parhamn

Awesome! Question, say you use TypeScript already, what are the biggest tangible gains in terms of safety (measured by fewer bugs in production) you think can be achieved by using Reason?

⬐ thegreatpeter

1. Pattern Matching

Pattern matching has been by far my most favorite feature as someone coming from TypeScript: https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394...

The ability to use "constants" that are inherently typed mean less mistakes and a better path forward for handling your application state.

Refactoring with this in mind, becomes a lot safer. For example, if I had a reducer that needed a new action, I would add that action to the `type`. The compiler would then tell me every place I needed to handle that case.

2."Implicit" Types (types that don't get in the way)

I don't need to type everything like I would in TypeScript. ReasonML already figures all of that out for me. I _can_ add the type if I want (for readability purposes). There is no such thing a `any` or any type of escape hatch for that (this can be frustrating at first) but once you get it, you write code more confidently.

3. React & Refactoring

Say I've got a bunch of React components I need to refactor. Reason types both the prop key and value. If I remove a prop or change that prop's data structure, I'll immediately know all the places I need to make that change.

I know some folks may roll their eyes when they read this, but after using both Reason and TypeScript at Draftbit, I strongly believe it's a competitive advantage. The stuff we ship in Reason just doesn't break.

⬐ machiaweliczny

Is it possible to compile in presence of errors? I love TS that it's gradual and for prototyping I can use "transpileOnly" and after I'm done I can verify everything. I have bad memories from typing json interfeces for Elm while prototyping (maybe could be disabled).

⬐ pkilgore

No, but you can slowly Reason-ify a javascript (or typescript!) app at the interfaces using gentype[1], which emits javascript/typescript/flow interfaces for the reason side. It works perfectly well to ship a slowly-becoming-reason frontend app.

But you do have to have the compiler give the thumbs up before it will compile the reason side of the project.

You can also checkout the tutorial for slowly converting a single file here, although I find myself doing this sort of thing very rarely: https://reasonml.github.io/docs/en/converting-from-js

[1] https://github.com/cristianoc/genType

⬐ bgorman

With ReasonML and other ML languages the type system is advanced enough to make many error conditions unrepresentable in the type system, and therefore the bugs move from runtime to compile time. Typescript has slowly been making its type system more powerful and exhaustive, but ultimately the fact that it is a superset of javascript will always keep it from having the compile time safety you can get in other languages.

ReasonML (OCaml) natively supports pattern matching, variants (Sum types), polymorphic variants, smart constructors, abstract data types, recursive types, and modules.

When you know how to use all of these features, you can prevent a remarkably large surface of bugs from ever compiling. As a new user, the first feature that will probably bring a smile to your face is pattern matching with variants.

If you are interested I highly recommend the book "Learn Type-Driven Development"

⬐ _bxg1

What's the editor support like? TypeScript has industry-leading editor integration with insanely fast response times. I'm always wary of new languages for this reason; I've been burned before by Facebook's own Flow type system.

⬐ dmit

Reason support in VSCode is very solid.

⬐ davesnx

That's not even true. It's still very early days for Reason VSCode tooling, since you might find a few extensions that support most of the cases but lacks a few key features that you might be used to while writing JS/TS.

⬐ shermanmccoy

I use the Reason Language Server and eglot in emacs on a linux system and it is very snappy. Reason-cli gives you code formatting also.

⬐ bgorman

As far as editor support, I have used reason-language-server (https://github.com/jaredly/reason-language-server) with Emacs (current), Vim and VSCode (provided through reason-vscode plugin).

I used to use IntelliJ, and there was a solid plugin for that as well.

ReasonML's compiler is way faster than Typescript's.

⬐ _bxg1

There's a difference between "the compiler is faster when run at the CLI" and "the language server is faster". A good language server remains responsive by doing quick, partial compilations on just the section that changed. A bad language server just wraps the standard compiler and re-runs the whole thing when a file is saved. The latter will eat up CPU/RAM and make for a frustrating dev experience, no matter how relatively-fast the base compilation time is.

⬐ yawaramin

OCaml (the Reason compiler) has historically had excellent (and fast) editor support tooling: Merlin.[1] That is now being packaged up as a language server (i.e., LSP).[2] Once you try a Merlin-based editor addon, everything else will seem dog-slow.

[1] https://github.com/ocaml/merlin

[2] https://github.com/ocamllabs/vscode-ocaml-platform

⬐ andrepd

True, I've been spoiled by merlin ;)

⬐ spyder81

The standard compiler can do a cold compile of a single file in milliseconds. When the compiler is that fast you _can_ just wrap it up and it'll still be faster than TypeScript.

But to answer your actual question: The current standard (reason-language-server) does simply wrap the compiler, and it's more than fast enough, but the community is working on a new merlin-based language server (ocaml-lsp) which does support partial compilation.

⬐ Scarbutt

I'll take super fast compilation first ;)

⬐ thegreatpeter

1. The language server, reason-language-server is written in native Reason and is _very_ fast.

In terms of compiler speeds, Draftbit has 1,000 ReasonML components and about 100 TypeScript files.

I can safely build AND type the entire ReasonML project before TypeScript returns the type results in watch mode.

⬐ davesnx

There are a few differences between both, a lot of people mention the fast compilation and the type inference.

I would add that the types from Reason are much "smaller" and concise, Option type or Result type and the immutability of Records/Objects creates an environment of safety that I don't have it in TypeScript.

⬐ cies

All good arguments in this thread. One I miss:

TS fixes some of JSs issues, but many it cannot fix by still being a super set of JS.

Reason is similar (enough) to JS syntax-wise, while not having to deal with it's quirks. This is huge for me.

⬐ muglug

I don't use Reason, but it looks like the main safety gain is immutability-by-default.

Whether or not that matters to you, though, will often depend on your general appetite for functional programming concepts.

⬐ yawaramin

- Full-fledged support for pattern-matching exhaustiveness check, not something you have to bake together using a 'tag' field. This means if you match on i.e. integers, the compiler will warn you if you don't include a catch-all default case.

- Simple module system where you don't need to deal with named vs default imports and all the weird bugs getting them mixed up can bring

- TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting to type a pair of parentheses:

    function isSupported(): boolean {
      return false;
    }

    function test() {
      console.log(true && isSupported); // true
    }

Or doing object/array indexing and forgetting to handle the case of 'undefined' because TypeScript doesn't enforce that. Or how any typings from before version 2 are suspect because they were written with the assumption that every type can be implicitly nullable. There are lots of these little footguns all over the place.

- Higher-quality bindings: more stuff captured at the type level, you're not left to deal with bindings full of 'any', 'object', and 'function'

It's not even just about safety though. One of the biggest productivity drivers in Reason is its iteration speed–the compiler is so fast that you can try out changes basically as fast as you can save the file. And there are other things, like how all modules are implicitly available in scope, so you don't need to manage a 'wall of imports' at the top of every file before you can actually get to the code itself.

⬐ Kaze404

> TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting to type a pair of parentheses

FWIW this was just fixed in TypeScript 3.9.

⬐ yawaramin

Interesting, can you link me?

EDIT: I just tried in the TypeScript Playground (v3.9.2), it's actually rather worse than I thought, it prints not 'false' but the actual function itself as a value...

⬐ Kaze404

https://devblogs.microsoft.com/typescript/announcing-typescr...

Edit: Apparently the functionality already exists as of 3.7. The update in 3.9 was to add it to ternary operations as well

⬐ yawaramin

Great. But looks like it doesn't work inside a boolean expression.

⬐ jordwalke

- It's Just JavaScript With Types

- It's Usable

- It Has Full Type Safety

Pick two.

I think the TypeScript is aware of the tradeoffs, have chosen the first two, and the result is a great developer/IDE experience for JavaScript programs (props!). Reason chooses the last two and creates a great experience for writing very safe web apps.

⬐ namelosw

Congratulations! I hope Reason and Reason React could get more tractions.

I'm wondering, will there be more marketing for Reason or Reason React after it reaching 1.0?

I found when introducing this kind of technology for day jobs, people either get confused or concerned usually, even though it really looks like React now.

It seems to be very hard to have programming languages taking off without marketing nowadays because the adoption usually comes from other people's adoption. It's the "threshold of immortality" of programming languages according to Simon Peyton Jones.

⬐ Matthias247

> - It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason

Did they move from Typescript or Javascript?

⬐ yawaramin

More details here: https://reasonml.org/blog/messenger-50-reason

⬐ dmitriid

> It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason

When they did that, I was running into numerous behaviour bugs on Messenger.com. Anything from weird image uploads to link previews not showing up in one chat but working in another etc.

Reduction in pure code bugs is nice and all, but a very synthetic and useless metric overall IMO.

⬐ Scarbutt

If the language has proved to be worthy, why messenger.com only though?

⬐ fulafel

This meritocratic model is unfortunately not really how language popularity plays out in the real world. At least not on career-length timescales.

⬐ Scarbutt

Was referring to Facebook usage only, like in, why isn't it used more at FB?

⬐ fulafel

I think the point stands doubly strong in case of Facebook. They're a PHP shop after all.

⬐ Scarbutt

PHP doesn't run in the browser...

⬐ fulafel

Sure, but using it in the backend tells us that there is no language meritocracy at FB.

⬐ jordwalke

It is.

⬐ vosper

I asked a similar question recently, one of the maintainers was nice enough to reply with some info. Perhaps this sheds some light: https://news.ycombinator.com/item?id=23116754

⬐ dmit

Congratulations on the release! I have a couple questions for you (and any other contributors!) about the project, but I don't know how to phrase them without coming off as combative. Please accept the following as genuine curiosity rather than malice.

1) You called the 0.8 release "huge" in the release notes, even though it adds 11 new functions, removes 2, and updates 2 compared to 0.7, released a year prior. Is there something else about 0.8 that makes it larger than the sum of the API changes?

2) BuckleScript has seemingly been a one-man show for ~3 years. It is lagging noticeably behind the progress of the main OCaml project (including jsoo). ReasonML has a couple prominent contributors, but the overall (public) activity is dwarfed by Hongbo Zhang's work on BS. Is this because the ReasonML project is considered to be in a stable state, sufficient for production work?

⬐ yawaramin

1) You can see a complete list of changes here https://github.com/reasonml/reason-react/blob/a70d9e6b51ed0a... . We consider it a huge release partly because it adds some long-awaited bindings, partly because of the documentation improvements, and partly because of how community-driven the release was.

2) BuckleScript's creator works for Facebook and has both a specific focus and a long-term vision for the project, more details here: https://www.youtube.com/watch?v=iWEQjvGGiTA . He also regularly blogs about ongoing improvements: https://reasonml.org/blog . Facebook Web Messenger and other products are heavily reliant on BuckleScript. I would consider that to be production-ready.

⬐ dmit

To clarify, the link in 1) is where I took the number of changes from.

And Re: 2) I have no doubt that Mr. Zhang knows what he's doing. I was just noting how even after the prodigious amount of work he has put into BS over the years, it is still falling behind JSOO which has the benefit of being more tightly bound to the parent OCaml project. I know about the different tradeoffs JSOO and BS have made. All I meant to say is that one super-productive person is apparently (and understandably) not able to keep up with upstream (i.e. Inria + Jane Street + many others) in this case. And then we have the ReasonML project that has seen even less activity recently. If ReasonML in its current state is considered a finished product that requires minimal maintenance, I couldn't think of a better endorsement, to be honest.

⬐ jordwalke

ReasonML is an umbrella project/sponsor for many subprojects, all of which have the goal of bringing fully type safe, fast compiling, fast executing code to the widest number of developers and today that means JavaScript developers. Many ReasonML projects support or improve upstream OCaml ecosystem. For example, package management workflows (https://esy.sh), interactive repls that work with Reason syntax, and OCaml syntax (see https://sketch.sh), and many community members contribute to the developer tools (next generation language server created by OCamlLabs). Others are building CI infrastructure, and many other projects. Reason Syntax was the first entry into the ecosystem. It's not done evolving/improving, and it's just the tip of the iceberg for all the projects under the umbrella. BuckleScript has been developed with Reason users in mind. Syntax is one of the most important things when introducing a language, and one of the biggest tripping points for new people trying out OCaml so it makes sense that it would be the first entry. But it's not the last, it's not the only, and it's not finished evolving/improving.

⬐ dmit

Thank you for taking the time to reply, Jordan, but none of what you posted is relevant to my concerns from the above two comments.

⬐ jordwalke

I believe it does address part of your comments. At the very least:

"And then we have the ReasonML project that has seen even less activity recently"

You comment seemed to be based on the assumption that the Reason syntax is the sum total of the Reason project, and I provided examples that would adjust that frame of reference. See the high level goal I mentioned - bring fast development, fast running, fully type safe programming to the largest audience possible. Syntax is one important piece, but not everything, and it's not everything under the ReasonML project umbrella.

⬐ dmit

Ah, you're right. I did judge the Reason project by the number of commits its main repo has seen in the past year.

But surely you'll agree that "fast development, fast running, fully type safe programming" has been achieved years ago, and any incremental improvements coming from the BS project are just that - incremental.

⬐ jordwalke

You forgot the most important part: "to the largest audience possible". I think that's the biggest disconnect here.

⬐ yawaramin

There must be a misunderstanding here, maybe on my side, but I honestly can't see how BuckleScript is 'falling behind': it jumped from 4.02.3 to 4.06 fairly recently, with more upgrades planned, and there is ongoing work to make it emit JS that looks more and more hand-written. Its download count looks like hockey-stick growth: https://www.npmtrends.com/bs-platform

Look, JSOO is great but it has a very different goal from BuckleScript: letting OCamlers use the Opam ecosystem to make frontend apps without caring about bundle size. And that's great, but it's not what JavaScript developers want.

⬐ dmit

I think you know what I mean. 4.02.3 was released in 2015. 4.06 was released in 2017.

Like I said, I know the tradeoffs between JSOO and Reason. And lack of features from the past 2~3 years of OCaml development is one of them.

⬐ yawaramin

Yes, if your only heuristic of 'falling behind' is 'not getting the latest OCaml features'. It turns out that even OCaml from a few years ago is perfectly usable to build an excellent JavaScript-focused compiler.

⬐ dmit

I think "getting OCaml features at a slower rate than OCaml itself does" counts as "falling behind", yes.

2015 OCaml was an excellent language. 2020 OCaml is exquisite.

⬐ drbojingle

What feature of 2020 OCaml do you think would convince JS developers to use Reason?

⬐ sgrove

Monadic let syntax would be a big win (allows for async/await-like constructs) in Bucklescript, and inline variant records have been nice once or twice (I see reason newcomers at dojos do this naturally almost every time shortly after introducing variants).

⬐ yawaramin

Inline records are available since BS 6 :-)

⬐ yawaramin

@dmit, we will have to agree to disagree there; the reality is, only a very few people are using the absolute latest OCaml features. If you look at the Opam package build matrix: http://check.ocamllabs.io/ ... most Opam packages are building against 4.02 to 4.05. And OCaml in 2020 is great but it's still not close to what we need for wider adoption in its chosen native compilation space. BuckleScript/Reason is a different strategy, which actually does seem to be working for that goal.

⬐ hongbo_zhang

Hi, the author of BuckleScript here. JSOO and BuckleScript has very different goals, the former focuses on the compatibility with native, while the latter focuses on the interop and optimal perf on JS backend. The progress of BuckleScript is actually much faster this year if you follow the development closely. OCaml as a language which has been developed for more than 20 years is quite usable without using the latest version, our top priority is to make js interop the best, it is not to catch up the lastest release (but we do have plans to sync up once every two years).

⬐ dmit

Please, you're driving me crazy. I have referred to you personally by name in two of my above comments. I know who you are! I also know about JSOO vs BS! I know! And it's super disorienting when every single prominent person from the Reason/BuckleScript ecosystem arrives in this thread just to reply directly to my comments with a canned message that has little to do with my original points.

Yes, OCaml is older! Yes, OCaml circa 2015 is a useful language! But also, yes, OCaml has gained multiple useful features since 2015! In part because its development is driver by many, many people. And no, BuckleScript doesn't have some of those features as of May 2020! And it's not an indictment of Reason, but it is also a true statement that Reason/BS are lagging behind compared to what OCaml has to offer!

⬐ yawaramin

You have half of the picture, I don't believe you have the other half, which is the progress that BuckleScript is actually making in emitting clean, readable JavaScript.

Fortunately, it's rather simple to see for yourself, you just need to head over to https://reasonml.github.io/en/try.html and try out some OCaml/Reason code and see what is emitted. In fact, the playground comes with various examples built-in, if you need some sample code to try out quickly.

⬐ wetmore

I'm an outsider but it appears to me that he's addressing your points. You are specifically comparing JSOO to BS and seem to be asking how can BS keep up? You got a response that they are two projects with two different goals, and hence they can't really be compared in the way you are comparing them.

I'm not sure what's driving you crazy about this interaction.

⬐ rickyvetter

I'm not OP but I work on ReasonReact. I think these are excellent questions - thanks for asking despite your worries about tone.

1. I would not classify this release as huge by most definitions, but I do think it is by a couple. First - it has many more contributors (both in code and on issues) than the 0.7 release and that means better reflection of community desires and direction. Second - it is the first release that forces 7.x BuckleScript which sets up ReasonReact for optimizations that would be impossible otherwise. Better support for `lazy`, `context`, and more.

2. BuckleScript is a true fork of OCaml and that comes with tradeoffs. On the plus you get JS interop you cannot achieve with JSOO (records and modules compiling to objects, https://bucklescript.github.io/blog/2020/03/26/generalize-un...). On the downside, active effort must be made and prioritized to upstream and maintain course with OCaml proper.

2a. Reason is being used in production at Facebook today, but Facebook also employs many of the people working on it. I personally consider it to be in a stable state for production use, but same as any technology I think it would be foolish to adopt Reason without better understanding the reason it exists, the problems it's trying to solve, and the drawbacks it has.

Jordan Walke, the creator of Reason (also the creator of React) said that syntax is unfortunately very important, because psychologically people want something familiar. I think syntax is totally superficial, but I’m also a human who interacts with other humans. And they do not think it’s superficial.

The talk where he says this: https://youtu.be/5fG_lyNuEAw

“Why isn’t functional programming the norm?” by Richard Feldman. Spoiler: not on the basis of merits. https://youtu.be/QyJZzq0v7Z4

“React to the future” by Jordan Walke. Why ReasonML is a logical extension of ReactJS’ programming paradigm. https://youtu.be/5fG_lyNuEAw

“Typing the untyped: soundness in gradual type systems” by Ben Weissmann. The trade offs that various gradual type systems make based on their language constraints. https://youtu.be/uJHD2xyv7xo

“Let’s program like it’s 1999” by Lee Byron. How the mutual feedback loop of abstraction, syntax and mental model drives the evolution of web technologies. https://youtu.be/vG8WpLr6y_U

⬐ Pandabob

Here's the secret agent ad by Sun which Feldman mentions [1]. These Sun ads are really quite entertaining and the production values have had to been through the roof at the time [2][3][4].

[1]: https://www.youtube.com/watch?v=NVuTBL09Dn4

[2]: https://www.youtube.com/watch?v=cfwMMI7hqns

[3]: https://www.youtube.com/watch?v=njnNVV5QNaA

[4]: https://www.youtube.com/watch?v=AP4FgXOlMh0

⬐ herbstein

> Why isn’t functional programming the norm?

This talk is very good. It's one of the few talks that I've overheard classmates talk about. It not only asks a question a lot of people exposed to functional programming at university asks, but also answers it in a way where you learn more about the world of programming and programming languages than you expected.

⬐ hardwaregeek

Maybe I'm missing something but I'm more than halfway through the "Why isn't functional programming the norm?" and it just seems to be a kind of haphazard recollection of programming language history. A lot of which isn't what I'd call entirely correct. Python's killer app was arguably first CGI scripts then data science. Java succeeded due to offering GC in a non scripting language, the JVM and possibly lots of marketing. PHP is having a mild renaissance with Laravel (not that I'd advocate for PHP, but people do seem to love Laravel).

There was quite a bit of time in between the invention of implementation inheritance and the whole "prefer composition to inheritance". It's quite possible OOP became popular due to implementation inheritance then realized it was dumb.

This info is still useful, but what I'd really love from a talk with that title is an analysis of functional programming languages and how they each missed the boat through either syntax, lack of tooling, or purity. And compare it to functional-ish languages like Rust, JavaScript, Swift and Kotlin. Then chart a way forward for function programming language adoption. Maybe that happens at the end of the talk.

⬐ kopos

A complete digress, but OOPS still shines in the domain of GUI widgets programming where there are a limited number of interfaces and a huge number of widgets (implementations) working with that interface. FP works conversely, on a limited data and a huge set of functions. Maybe in the context of now with limited gui programming, FL is more suitable?

⬐ dnautics

Functional ui is arguably saner, as react is slowly proving to junior programmers worldwide.

⬐ MaxBarraclough

> seems to be a kind of haphazard recollection of programming language history

Agree. The talk is very thin on the real differences between OOP and functional languages.

This old comment [0] points out that functional languages tend to make it far harder to reason about low-level details, for instance.

Personally I think it's more fundamental, and isn't about any such technical limitations. People have a strong intuition for time, which is emphasised in imperative languages (including OOP), which have the semicolon operator or an implicit equivalent. The concepts at play in the fundamentals of Haskell are simply harder, and 'more mathematical', than the sequenced mutation-based statements of imperative/OOP languages.

To put that more provocatively: does anyone doubt that the average Haskell programmer is smarter than the average JavaScript programmer? I'm not convinced this is just because only the curious bother to learn Haskell.

[0] https://news.ycombinator.com/item?id=21281004

⬐ yawaramin

Here's Jordan in 2014 talking about OCaml: https://news.ycombinator.com/item?id=7766315