Full type inference, pattern matching with exhaustivity checker, modules, abstract types, ...

But to be honest, it's not very useful to do checklist-style comparisons — writing OCaml/Reason code is a completely different experience.

For me it results in less worry about how my code would sustain under refactorings — this is one of the reasons I feel more productive with it rather than with TypeScript or Flow or (of course!) plain JS. I can start writing code and don't worry about getting everything right upfront — refactorings are cheap.

I have replied to this question on SO [1], here is quote:

In a large application you will need a lot of features, which are provided by default in ReasonML: strict types, runtime validation if you encode/decode JSON, fast compilation time, immutable data.

In TypeScript you will have to add:

1. ImmutableJS + its typings.

2. Runtime validators like json-schema + its typings. Then you will have to write types in TypeScript, and also defined a schema in json-schemas. They can become out of sync very soon.

3. Some crazy hacks to tell the difference if variable is of specific type (like in official docs of TS: https://www.typescriptlang.org/docs/handbook/advanced-types...., Paragraph "User-Defined Type Guards"). This checks are done using side effects like a.swim !== undefined. In 6 months this 'if' statement will contain more and more checks.

4. You are lucky if a package you use has official and maintained type definitions. Or you will end up with custom typings.

5. If you develop hybrid app in JS + TS, then TS Compiler cannot create a bundled final d.ts file which you can import in other parts of your project. You will have to write separate d.ts files, which are bundled by tools like dts-bundle. If you have everything in TS, then this issue is not applicable.

6. Large apps take a lot of time to be compiled by TypeScript.

With ReasonML:

1. Immutable data is in the language.

2. Runtime validators are present (bs-json has them by default).

3. Pattern matching saves you from these crazy checks.

4. You are lucky if npm package you want to use has BuckleScript bindings.

5. N/A.

6. ReasonML compilation is very fast.

1: https://stackoverflow.com/questions/46147250/reasonml-vs-typ...

Hi, I work on Reason: To add to other comments: One thing that ReasonML can do that TypeScript cannot do, is take advantage of the world-class OCaml compiler to generate very fast native executables. If you learn Reason, then you are also a "native developer" in a sense.

In my opinion one of the most useful features is first-class support for algebraic data types. Using records and variants ('sum' and 'product' types) in Reason one can be much more expressive in terms of how program state and other constraints are defined.

One can get some of the same benefits of sum types in TypeScript using discriminated unions - but the syntax is cumbersome and requires boilerplate as compared to Reason.

Pattern matching with a sane syntax.

https://reasonml.github.io/docs/en/pattern-matching.html

TypeScript has to handle every JavaScript quirk, it puts structure in place to help mitigate many issues.

ReasonML breaks from full compatibility, it can pick and choose JavaScript features to compromise between familiarity and functionality.

At the other extreme you have Elm, which has a similar background but won't compromise so can offer a clean break from JavaScript.

Prevent null bugs.

Typescript values can be null. A pure reason program will never have null bugs.

https://reasonml.github.io/docs/en/type.html

If you look at language itself many things. It's different paradigm.