5 ms·

What can ReasonML do that TypeScript can't?

by azr79 9y ago

tango12 9y ago
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 https://reasonml.github.io/docs/en/type.html
- billwashere 9y ago
  In case anyone didn't know, since Typescript 2 there is a compiler option to enable strict null checking. https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-nullable-types https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...
  - realharo 9y ago
    Only since 2.7 (very recently) can you actually enforce initialization of class properties: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#strict-class-initialization https://www.typescriptlang.org/docs/handbook/release-notes/t...
    - Rapzid 9y ago
      I was just wondering about this today; thx for the link! Not sure how I missed it.
      - realharo 9y ago
        Unfortunately, libraries such as React have their own component lifecycle management, which doesn't play well with this (https://reactjs.org/blog/2015/12/18/react-components-elements-and-instances.html https://reactjs.org/blog/2015/12/18/react-components-element...). This is also a bit of a pain point on Android with Java @NonNull annotations or when using Kotlin.
        Rapzid 9y ago
        Yeah... It would honestly be cool to have a TypeScript native React(as crazy as that sounds). There are some really great projects out there killing it like Nest, MobX, TypeORM, etc.. The React typings have come a long way though. I do quite a bit of TypeScript for the server though(less context switching and is mostly GoodEnough™) so still handy.
        azr79 9y ago
        Angular plays very well with typescript, because the entire framework is written in it, more than that, Angular Team is working with TypeScript Team to help make TS better, and vice-versa.
- azr79 9y ago
  Not true, TS has strict null checking
napa15 9y ago
compile quickly
fleetfox 9y ago
If you look at language itself many things. It's different paradigm.
TuringTest 9y ago
Pattern matching with a sane syntax. https://reasonml.github.io/docs/en/pattern-matching.html https://reasonml.github.io/docs/en/pattern-matching.html
andreypopp 9y ago
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.
jordwalke 9y ago
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.
bobbby 9y ago
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.
- cies 9y ago
  > ReasonML breaks from full compatibility It promises zero compatibility code wise, but very easy interop (FFI) with JS land!
gladimdim 9y ago
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.html 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-typescript/47944310#47944310 https://stackoverflow.com/questions/46147250/reasonml-vs-typ...
dsiegel2275 9y ago
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.

What can ReasonML do that TypeScript can't?

by azr79 9y ago

What can ReasonML do that TypeScript can't?

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 https://reasonml.github.io/docs/en/type.html

billwashere 9y ago
In case anyone didn't know, since Typescript 2 there is a compiler option to enable strict null checking. https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-nullable-types https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...
- realharo 9y ago
  Only since 2.7 (very recently) can you actually enforce initialization of class properties: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#strict-class-initialization https://www.typescriptlang.org/docs/handbook/release-notes/t...
  - Rapzid 9y ago
    I was just wondering about this today; thx for the link! Not sure how I missed it.
    - realharo 9y ago
      Unfortunately, libraries such as React have their own component lifecycle management, which doesn't play well with this (https://reactjs.org/blog/2015/12/18/react-components-elements-and-instances.html https://reactjs.org/blog/2015/12/18/react-components-element...). This is also a bit of a pain point on Android with Java @NonNull annotations or when using Kotlin.
      - Rapzid 9y ago
        Yeah... It would honestly be cool to have a TypeScript native React(as crazy as that sounds). There are some really great projects out there killing it like Nest, MobX, TypeORM, etc.. The React typings have come a long way though. I do quite a bit of TypeScript for the server though(less context switching and is mostly GoodEnough™) so still handy.
        azr79 9y ago
        Angular plays very well with typescript, because the entire framework is written in it, more than that, Angular Team is working with TypeScript Team to help make TS better, and vice-versa.
azr79 9y ago
Not true, TS has strict null checking

napa15 9y ago

compile quickly

fleetfox 9y ago

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

TuringTest 9y ago

Pattern matching with a sane syntax. https://reasonml.github.io/docs/en/pattern-matching.html https://reasonml.github.io/docs/en/pattern-matching.html

andreypopp 9y ago

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.

jordwalke 9y ago

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.

bobbby 9y ago

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.

cies 9y ago
> ReasonML breaks from full compatibility It promises zero compatibility code wise, but very easy interop (FFI) with JS land!

gladimdim 9y ago

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.html 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-typescript/47944310#47944310 https://stackoverflow.com/questions/46147250/reasonml-vs-typ...

dsiegel2275 9y ago

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.