Its difficult to work on a developer tool without actually getting benefit to yourself from working on the developer tool. Suspect flow will go through a rewrite (after getting sufficiently annoyed by OCAML tooling) at some point, but TypeScript is already there.
TypeScript vs. FlowType
BASARAT
1466

Hey — Nice article :-)

Since there are a few things which seem a little bit one-sided, I want to provide some information on the flow related part:

Because TypeScript is written in TypeScript (which in turn is just JavaScript), it makes a lot of things possible e.g. in browser playgrounds

OCaml uses BuckleScript to compile to very efficient JavaScript as well. You can even use the flow-parser in node.

We also have a playground in flow, which runs in the browser: https://flowtype.org/try/

Its difficult to work on a developer tool without actually getting benefit to yourself from working on the developer tool. Suspect flow will go through a rewrite (after getting sufficiently annoyed by OCAML tooling) at some point, but TypeScript is already there.OCaml is here to stay. Better yet, I believe that some people will even adapt to ReasonML / OCaml as a “Compile-to-JavaScript” language for their application code.

We sure do benefit from our tools, although it is not 100% apparent… maybe it is not apparent because of OCaml.

The language is not well known indeed, but in the React community, I see an rising interest in alternative functional programming languages like Elm, which has its roots from HASKELL as the language compiler… not TypeScript… not JavaScript… HASKELL! It’s all about the best tool for the job and OCaml + Haskell have proven to be a good fit for building compilers, because of their real type-safetiness, functional paradigms and runtime speed.

I like that TypeScript tries to change the way people thing about static types in JavaScript and tries to make it easier for people to contribute to the compiler and ecosystem.

Although in my opinion, a programming language is not the major problem in contributing to the compiler itself..

It’s the complexity of the problem, we try to solve.

I don’t care in what language I need to write an AST-parser in… it’s usually the problem to understand how an AST-parser actually works…

Anyways, I personally like the choice of technology flow did and I am really happy to learn a lot from the OCaml community as well.

Plus, I really recommend everyone to have a look at the flow repository, check out all those awesome tools which are also build in ES6 JavaScript (with flow annotations of course) and maybe have a look at some OCaml source… I mean, who knows… maybe you like it?

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.