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

271–280 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#271

Post by avik »

paulddraper wrote: post #190

Similar to the Google Closure Compiler ( https://developers.google.com/closure/compiler/ ), which has been around for years, just with fewer features. It has static type checking with optional type annotations and type inference. It doesn't have compiler-time constants, dead code removal, inlining, or other optimizations. But....still really cool.

One obvious thing to try is to use Flow's type inference to emit GCC annotations and see whether those optimizations kick in. (Of course, Flow can also try to replicate whatever GCC does, but that will take some time. No reason not to, though.)

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#272

Post by avik »

slashnull wrote: post #105

Another comment that just occurred to me: JavaScript becoming gradually typed is an interesting reflection of the recent history of the optimization of JavaScript interpreters, which consist of deducing where semantically dynamic objects behave like static class instances, then inlining the accessors and where beneficial, the "class methods", and specializing && JITing the semantically dynamic functions that almost a…

Yes, so the conclusion one might draw is that if your code is implicitly typed, it will run fast as well as probably do well when run through a static type checker.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#273

Post by avik »

hyp0 wrote: post #187

Static types without performance benefits. So far, all popular static type systems have had the performance benefits, so it's unclear how much people value the other benefits (quality and documentation). I wonder which will have the most impact: code quality or types as documentation (esp for tooling)? They are adapting to common idioms, rather than designing it from the ground up. This ad hoc approach is a great way…

If you can feed inferred static types to something like Google Closure Compiler, you do get performance benefits.

Also, if you're code is implicitly statically typed (as checked by Flow) you will likely hit all the right optimizations in the underlying JavaScript VM.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#274

Post by avik »

hyp0 wrote: post #195

One of the authors of Flow offered to answer questions, but their comment is greyed out as a dupe (and it isn't a dupe - something went wrong): https://news.ycombinator.com/item?id=8625406

Haha, yeah Hacker News didn't treat me well yesterday, so I'm trying to go through questions now and reply to them. :) Thanks for noticing!

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#275

Post by avik »

alkonaut wrote: post #55

How does static checking work with dynamic types? Can the type checker figure out if a field/method exists on a type given that it can be added dynamically? Edit: I assume it just checks bool/number/string and doesn't care about prototypes?

It does care about prototypes. So it checks for inconsistencies between methods added to a prototype and their uses. The tradeoff is that for dynamically added properties, it doesn't always remember where they are defined and where they remain undefined (it knows they are defined "somewhere").

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#276

Post by avik »

bri3d wrote: post #38
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.

The source also has an emacs plugin, named flow-types.el

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#277

Post by dang »

hyp0 wrote: post #195

One of the authors of Flow offered to answer questions, but their comment is greyed out as a dupe (and it isn't a dupe - something went wrong): https://news.ycombinator.com/item?id=8625406

If you see "[dupe]" on a dead comment you can be sure that that is why it was killed.

The problem was that there were two identical comments, the software killed one as a dupe, and avik deleted the other one. The software tries to fix this very scenario—it normally would have automatically unkilled the remaining member of the pair. But there are some corner cases where that doesn't work, and avik seems to have outsmarted it.

We'll take a look and try to fix the fix.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#278

Post by avik »

hyp0 wrote: post #191
avik wrote: post #160

Earlier quoted context omitted.

We have some basic editor support, more is coming soon. Flow exposes several commands that are useful through an editor, like type-at-pos (give it a position, it gives you back the inferred type), suggest (give it a file, it dumps out an annotated file), autocomplete (gives you suggestions at a given position), etc. Also, we require annotations at module boundaries, so you're modules are going to have well-typed inte…

I strongly agree with module typing (and being more relaxed within). Because of caller dependence on modules, the difficulty of changing static types becomes a benefit. Plus, they need to be documented anyway; and tooling support helps use they as if they were primitives. As others have said, I love the approach of inference giving static type benefits, for free. If you get tooling support, at no extra work, why not…

Still early days but the reception has been strongly positive. We may be a biased bunch but we like our code mostly statically typed with the flexibility provided by dynamically typed languages. A large part of this culture is due to the immense internal success of Hack (http://hacklang.org/).

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#279

Post by tripzilch »

denizozger wrote: post #171
kulkarnic wrote: post #127

Earlier quoted context omitted.

Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…

The bad parts are there, but as of today it's a very powerful language that runs on every browser (hence every computer in practice?) with massive community support.

> hence every computer in practice?

Oooh, there's many more computers around you than you think ;-) Nearly every modern piece of electronics. Many don't run browsers. For instance your washing machine has an OS, but it probably doesn't run Javascript. Same goes for your car, washing machine, dishwasher, microwave, central heating system, stereo/hifi, etc. And of course the more obvious "non-PC computers" like routers, printers, scanners, TV (might actually run JS if it's "smart" and has a browser), computer monitor and who knows what else. Coffee machine. The "fancier" it is (for a rather low barrier of "fancy"), the more likely it is to have a chip in it that runs some firmware/OS something, equal in power of what people ran as desktop personal computers a few decades ago.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#280

Post by nextw33k »

ajuc wrote: post #217
ricardobeat wrote: post #216

Earlier quoted context omitted.

Server-side js has that already. On the clientside it would be useless.

What about p2p?

There is a problem with JavaScript in that there is no security mechanism currently in place to ensure the JS file you are running is what you expect to be running.

Imagine your on your favourite social network that used a JS based encryption in a p2p chat to your friend. On that same page advertisers are pushing content to you. That content could be a malicious JS file which can eavesdrop on your conversation, all the while you think its encrypted.

Post reply on HN