5 ms·
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
by 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 agoWhat'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 agoReason support in VSCode is very solid.
- davesnx 6y agoThat'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 agoAs 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 agoThere'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 agoOCaml (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 agoTrue, I've been spoiled by merlin ;)
- thegreatpeter 6y ago1. 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.
- Scarbutt 6y agoI'll take super fast compilation first ;)
- spyder81 6y agoThe 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.
- shermanmccoy 6y agoI 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.