Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook Launches Flow, Static Type Checker for JavaScript

code.prod.facebook.com

Post reply on HN
Print view View original

31–40 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#31

Post by slashnull »

At last!

This all seem extremely cool.

I went straight from hacking Scala and Haskell as a hobbyist to doing (mostly) front-end JS job, and I've always found that my code, and a lot of good libraries I read, naturally emulate something close to Hindley-Milner typing, by using objects as tuples/records and arrays as (hopefully well-typed) lists, as well as the natural flexibility of objects as a poor substitute for Either types.

I'm definitely pleased to see that the designers of this library have also realized that strongly-typed javascript was just a few annotations and a type inference algorithm away.

I'm just wondering why are nullable types inmplemented as such and not as a natural consequence of full sum types, which are inexplicably absent.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#32

Post by DougBTX »

masklinn wrote: post #25
fdomig wrote: post #14

From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with tsc --noImplicitAny hello.tsc which will result in hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type. I do not see much difference. [1]: http://flowtype.org

TS bolts on a straightforward nominative type system without type unions (or non-nullable types), so it can't handle a variable typed as `number | string`, it'll immediately drop down to `any`. That is, flow aims to remain useful in the face of more JS idioms. It won't make a difference between nullable and non-nullable either, so AFAIK function length(x) { return x.length; } length(null); can never be a compile-time…

Yep, here's some related discussion: https://github.com/Microsoft/TypeScript/issues/185

tl;dr: they want to support both of those features, the question is what syntax to use and how to introduce those features into the existing ecosystem.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#33

Post by jspdown »

MrBuddyCasino wrote: post #8

That is quite impressive. No type annotations needed, and control flow is taken intro consideration (hence the name I guess). If I am not mistaken, this tech could be used to build IDEs roughly similar to whats available for Java, couldn't it?

There are ambiguous case where you need to specify a type to obtain the expected error.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#34

Post by slashnull »

inglor wrote: post #29
drderidder wrote: post #11

Static analysis is definitely preferable to cross-compilation and this looks like a great tool. That said, the idea that static type checking makes developers more productive and prevents tons of errors is overstated imho. Type inference is supposed to make coding simpler and more productive (particularly in functional languages) - even C++11 has added it. I'm sure static type checking can benefit some organizations,…

This is a form of cross-compilation kind of like how TypeScript is cross compilation. It does require a build step to produce JavaScript - you will not be able to enjoy fiddles as easily and so on. Then again their rationale is very clear and pretty good: You need builds if you're using Facebook's stack anyway (for JSX) so this should not interfere with your current build - which you have to do anyway.

If only to remove syntactically invalid type annotations, I guess. Strong typing is not incompatible with the absence of run-time typing information, due to the magic of type erasure.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#36

Post by inglor »

judah wrote: post #18
fdomig wrote: post #14

From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with tsc --noImplicitAny hello.tsc which will result in hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type. I do not see much difference. [1]: http://flowtype.org

One major difference is the null checking. From what it looks like, they've added an additional type, "maybe", that represents a possibly-null object. TypeScript doesn't have that concept, although it's been suggested by the community more than once.

Here is some interesting discussion on that aspect of the typesystem: https://github.com/Microsoft/TypeScript/issues/14 It also discusses Flow from 2 months ago (from a now removed video)

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#37

Post by jimarcey »

drapper wrote: post #10

How this compares to TypeScript? At the quick glance I noted: - more powerful type system (union types, hurray) - support for JSX - no windows binaries - supports more of ES6 stuff - ...but has no support for modules yet - no generics (??) How about performance? and workflow? Didn't yet find this: does it use a normal "write then compile" model like TS or has something like Hack (if I'm not mistaken it has a daemon r…

There is no real compile time step with respect to type checking. Flow (like Hack) analyzes and type checks in the background, realtime.

For workflow, check out: http://flowtype.org/docs/getting-started.html#_

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#38

Post by bri3d »

MrBuddyCasino wrote: post #8

That is quite impressive. No type annotations needed, and control flow is taken intro consideration (hence the name I guess). If I am not mistaken, this tech could be used to build IDEs roughly similar to whats available for Java, couldn't it?

It looks like it's designed for the IDE use case - on cursory inspection of the code, it contains an autocomplete database and a client-server architecture designed for editor plugins (with useful interfaces like "type at character index").

I'm surprised that they don't seem to have launched with a public editor plugin and that the documentation doesn't seem to mention it.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#39

Post by DigitalSea »

What a great tool. Facebook are absolutely killing with the last year or so with all of their open source contributions and releases. First HHVM, Haxl, React.js (amongst other things) and now Flow, this is fantastic. I am really liking how companies like Facebook & Google are concentrating their efforts on the web language of the future: Javascript. The support for JSX alone is a MASSIVE feature (expected given React.js and JSX).

Good job Facebook.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#40

Post by stiff »

drderidder wrote: post #11

Static analysis is definitely preferable to cross-compilation and this looks like a great tool. That said, the idea that static type checking makes developers more productive and prevents tons of errors is overstated imho. Type inference is supposed to make coding simpler and more productive (particularly in functional languages) - even C++11 has added it. I'm sure static type checking can benefit some organizations,…

JavaScript is a bit special in this respect, I think. Because of the weird type coercion rules, and how it treats null, undefined and because of the presence of NaN many common coding mistakes end up producing mysterious errors pointing somewhere far away from the place in the code that actually produced the problem in the first place. Basically JavaScript continues propagating null/undefined/NaN in many situations where other languages, including other dynamic ones like Ruby and Python, raise an error much earlier.

There are other issues as well, JavaScript doesn't check function arity on function calls (the arguments not supplied just get the "undefined" value), control structures do not introduce a new lexical scope etc.

Post reply on HN