Having spoken extensively to users of both Flow and TypeScript, these examples are entirely contrived because they're just demos. How often do you have a function that multiplies two numbers and returns it?
Examples are contrived because they are examples. There is no point in using 100-lines long "real-life" function. It will work the same way.
And, to be fair, I have to write functions like this fairly often:
const rad2deg = rad => 180 * rad / Math.PI;Real-life enough?
What ends up happening in TypeScript is that you write a few top-level types on your parameters, and typically the rest follows for you. Types flow in both directions and it just works.
Types don't flow in both directions in TypeScript, that's exactly the difference between Flow and TypeScript.
So you have to ask yourself: at the point that you want a type system, will you have multiple files? Probably. So at that point, the process of where you need types ends up being the same.
This is logically incorrect. The right question to ask is what is the ratio of functions you are going to export vs you are not going to.
The code coverage mentioned in the article is less actionable than TypeScript's noImplicitAny. Knowing that your code is 90% "typed" is useless if you're not sure what the last 10% is
This is incorrect. Code coverage is very actionable, you get locations of uncovered code and get a chance to change them.
No, I'd say that TypeScript intentionally infers from different locations.
Typescript doesn't infer from different locations, it infers from fewer locations.
This has to do with providing type-checking that aims to be correct rather than optimistic. Inferring from everywhere often means trying to pick the most optimistic type, which in turn can be less correct - it can miss true errors in your program.
This is an attempt to show that Flow is optimistic and TypeScript is correct, while it's the other way around. Indeed, Flow tries to find more general type when TypeScript doesn't. It doesn't make Flow optimistic or incorrect, it makes it complete.