4 ms·

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 b

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?

bgorman 6y ago
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 6y ago
  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 6y ago
    Reason support in VSCode is very solid.
    - davesnx 6y ago
      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.
  - bgorman 6y ago
    As far as editor support, I have used reason-language-server (https://github.com/jaredly/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 6y ago
      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 6y ago
        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 https://github.com/ocaml/merlin [2] https://github.com/ocamllabs/vscode-ocaml-platform https://github.com/ocamllabs/vscode-ocaml-platform
        andrepd 6y ago
        True, I've been spoiled by merlin ;)
      - thegreatpeter 6y ago
        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.
      - 6y ago
  - shermanmccoy 6y ago
    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.
deleted 6y ago
[deleted]
yawaramin 6y ago
- 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 6y ago
  > 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 6y ago
    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...
    - jordwalke 6y ago
      - 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.
thegreatpeter 6y ago
1. Pattern Matching Pattern matching has been by far my most favorite feature as someone coming from TypeScript: https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394e6091 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 6y ago
  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 6y ago
    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 https://reasonml.github.io/docs/en/converting-from-js [1] https://github.com/cristianoc/genType https://github.com/cristianoc/genType
davesnx 6y ago
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 6y ago
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.

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?

bgorman 6y ago

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 6y ago
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 6y ago
  Reason support in VSCode is very solid.
  - davesnx 6y ago
    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.
- bgorman 6y ago
  As far as editor support, I have used reason-language-server (https://github.com/jaredly/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 6y ago
    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 6y ago
      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 https://github.com/ocaml/merlin [2] https://github.com/ocamllabs/vscode-ocaml-platform https://github.com/ocamllabs/vscode-ocaml-platform
      - andrepd 6y ago
        True, I've been spoiled by merlin ;)
    - thegreatpeter 6y ago
      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.
    - 6y ago
- shermanmccoy 6y ago
  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.

deleted 6y ago

[deleted]

yawaramin 6y ago

- 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 6y ago
> 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 6y ago
  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...
  - jordwalke 6y ago
    - 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.

thegreatpeter 6y ago

1. Pattern Matching Pattern matching has been by far my most favorite feature as someone coming from TypeScript: https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394e6091 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 6y ago
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 6y ago
  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 https://reasonml.github.io/docs/en/converting-from-js [1] https://github.com/cristianoc/genType https://github.com/cristianoc/genType

davesnx 6y ago

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 6y ago

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.