3 ms·
Flow has better inference and is actually pursuing a sound type system. const f = function(a) { return a * 3; } f("stuff"); this will produce a runtime error
by leshow 10y ago
Flow has better inference and is actually pursuing a sound type system.
const f = function(a) {
return a * 3;
}
f("stuff");
this will produce a runtime error with TS, Flow will fail to compile it.
People here think that choosing a statically typed language necessarily means you need to type annotate everything, and thats not true. In Haskell and Elm you don't have to explicitly write any types if you don't want to.
Elm doesn't produce javascript that contains runtime errors, and Flow is pursuing a similar goal.
- KirinDave 10y ago> const f = function(a) { return a * 3; } f("stuff"); Right but the instant you annotate a, it knows and gives you a good error. The reason TypeScript did this, to hear them tell it at Build, was because (unlike Flow, although they did not say it) they're a transpiler with a mission to actually make the tool usable with real world javascript. That's why, for example, type errors don't block code emitting but syntax errors do. It's in service of making a usable toolchain. Flow can be more aggressive because it's not making these decisions (its part of a larger configurable toolchain). Neither Flow nor Typescript can actually project soundness onto Javascript. Mentioning that is a giant red herring. So long as compatibility with base ecmascript is offered there is code which cannot be verified as sound or unsound without the execution context at hand. Typescript takes the approach that types are actually a useful tool for expressing concepts succinctly and safely and offers that first. Flow takes the approach that aggressive type inference is a phenomenal way to detect (potential) errors in javascript code, and takes that approach. Neither is wrong.
- leshow 10y ago> Right but the instant you annotate a, it knows and gives you a good error unless you annotate it with :any > Neither Flow nor Typescript can actually project soundness onto Javascript. Mentioning that is a giant red herring. So long as compatibility with base ecmascript is offered there is code which cannot be verified as sound or unsound without the execution context at hand. I don't see how you can say that. Flow can absolutely create a 'sound' type system on top of javascript. Elm transpiles to javascript and has a sound type system that doesn't produce runtime errors. Flow has different syntax but it restricts the type system in a similar way.