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

101–110 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#101

Post by nbm »

pgroves wrote: post #94

Does someone know how these types of projects come to fruition in a big company like Facebook? Are people working on them full time (with no other workload)? Do engineers build them on the weekend? How do they get 'funded'?

That is a surprisingly hard question to answer.

I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever).

They generally aren't solutions seeking problems - they are responses to problems that exist.

Engineers generally don't build things like this on the weekend - unless they like to structure their time like that, I guess. It may or may not be a full-time job, but the job whatever it is isn't some search for abstract perfection, it is again to solve real problems encountered by others in the company. Often it is a part-time component built as part of trying to solve some more direct goal - like fighting spam, or serving bits, or whatever.

Often it is something the engineers just do - it makes sense to break things up into libraries, or services, or whatever, and they do that, and then that library or service is usable/useful elsewhere, and that's it. Other times they may suggest and motivate it as a goal-in-itself in a team goal setting situation.

I doubt that's a particularly useful answer, but maybe with further questions I can make it more useful to you?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#102

Post by Touche »

arjie wrote: post #93
Touche wrote: post #88

Earlier quoted context omitted.

I just use asserts for this. If code is sensitive to a type I assert it as the top of the function. No analysis needed.

But in a rare code path, that may not to be triggered. And if you write a unit test solely to catch the fact that the type is necessary, then obviously using a static type would be better because you get the benefit without the extra code for the test. Having optional typing does save you the trouble of overly complicated types for things where you aren't particularly concerned.

I don't understand what you mean by "But in a rare code path, that may not to be triggered." Can you explain?

I wasn't suggesting using tests; I was suggesting using asserts. Directly in the function that is type sensitive. If that function is ever called with an incorrect type it will throw an exception.

I get the benefit of optional type checking without a compile step in development like with Flow.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#103

Post by ep103 »

inglor wrote: post #78
ep103 wrote: post #68

This looks like such a better step in the right direction than than the types of tools MS and Google have been putting out. Dynamically discerning the underlying code, and allowing optional type annotation works _with_ javascript, as opposed to attempting to turn js into a completely different (and weakened) language. That said, I am curious what solutions this solves that isn't already solved by enforcing good code…

Well, here are some things that it does that other tools don't: - It type checks JSX - It supports some ES6 features others don't (like destructuring) as the build step - It has union types (TS will get those soon, already in master) - It does a lot more inference and a lot more assumptions. It assumes you won't multiply a string by a number for example (although technically '10' * 5 is legal in JS). So it's opiniona…

I digress but...

you're not wrong, but out of curiosity, I just genuinely wonder how often modern programmers really hit type errors on smaller projects (obviously not FB size). I don't think I've ever had a type cast bug in my js code, provided we don't include accidental nulls in that statement. So in my experience, if I were ever told that I now had to always use annotations, I would feel like I was losing flexibility in the language for little gain. And I feel like the reason I never hit type issues, is because I write full test coverage, which in turn make it painfully obvious what is and is not expected in each method.

For the reasons above, I love the idea of this tool dynamically checking all my code paths, and looking for things that are likely mistakes or result in null exceptions.

But I'm afraid to recommend this to my boss, for fear that for now on, everything must be maximum static... everything annotated, no union types, etc.

Just my 2 cents.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#105

Post by slashnull »

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 always take as argument "instances" of this "class".

(ref this absolutely fascinating paper

http://bibliography.selflanguage.org/_static/implementation....

and this piece of V8 dox quoting the aforementioned paper

https://developers.google.com/v8/design)

It seems that adding a type system to a dynamic language has little real drawbacks compared to designing language and type system at the same time, for both performance and type safety considerations.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#106

Post by arjie »

Touche wrote: post #102
arjie wrote: post #93

Earlier quoted context omitted.

But in a rare code path, that may not to be triggered. And if you write a unit test solely to catch the fact that the type is necessary, then obviously using a static type would be better because you get the benefit without the extra code for the test. Having optional typing does save you the trouble of overly complicated types for things where you aren't particularly concerned.

I don't understand what you mean by "But in a rare code path, that may not to be triggered." Can you explain? I wasn't suggesting using tests; I was suggesting using asserts. Directly in the function that is type sensitive. If that function is ever called with an incorrect type it will throw an exception. I get the benefit of optional type checking without a compile step in development like with Flow.

Well, I assumed you'd want to spot that error before it happens rather than when it does. The exception being thrown by the assert (at run-time) means that the user sees the failure. That's sub-optimal, right? So you'd ensure that there is testing of all code that calls this code in order to trigger the exception ahead of time if that occurs. Or am I misunderstanding? It just seems that the assert applies the constraint too late in the process. It doesn't ensure you have the right type once you've deployed. Instead it ensures failure on wrong type, which is something different.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#107

Post by logicalmind »

nbm wrote: post #101
pgroves wrote: post #94

Does someone know how these types of projects come to fruition in a big company like Facebook? Are people working on them full time (with no other workload)? Do engineers build them on the weekend? How do they get 'funded'?

That is a surprisingly hard question to answer. I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever). They generally aren't solutions seeking problems - they are responses to problems that exist. Engineers generally don't build things like this on the…

I find this type of work within companies (like google's famous 20% rule) an interesting contrast with non-tech companies. At a "normal" company if you attempt to spend time doing something of this sort, you'd get immediate pushback from higher ups who would likely say "this is not our core competency". With the secondary excuse being that they would not want to release any work like this for fear that it would help the competition.

It does raise the interesting question of whether facebook employees are doing this work just to avoid the work that is the "core competency" of the company. Especially given the fact they don't gain a competitive advantage from releasing the work that facebook paid for into the wild. By this I mean, the company benefit would seem to be attract other talent. And the personal benefit for the devs is to get their name out there are something cool and interesting. Certainly, working on the best way to advertise to users is a lot less exciting/sexy than working on static type checking for javascript.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#108

Post by a-saleh »

ep103 wrote: post #76
slashnull wrote: post #70

Earlier quoted context omitted.

So what's wrong with having a tool to automate those practices ; )

This is a bit off topic, but I digress.... I specifically didn't send this tool to the team I work on, because my team lead is a sql / java / c# guy who loves static languages, and only touches the front end with a stick if he has to, and then only some basic jQuery or angular. I've sold him on jasmine and requiring front end test coverage, recently. But right before I hit the send button I realized that if I sent hi…

Try to sell him on type-inference first?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#109

Post by SloopJon »

poxrud wrote: post #104

Looks like a great tool. The documentation at http://flowtype.org/ is excellent. Should be easy to add it to a Gulp/Grunt workflow.

I'm confused by the usage of the utility itself. I ran it on the hello.js, and it reported the expected type mismatch. I then tried to run it on the file in the answer sub-directory, but it kept telling me about the previous file.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#110

Post by drderidder »

drderidder wrote: post #41
inglor wrote: post #29

Earlier quoted context omitted.

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.

Really? It appears to be much more of a static analysis tool than a cross-compiled psuedo-syntax. Here's what it outputs: flow examples/01_HelloWorld/hello.js /hello.js:7:5,19: string This type is incompatible with hello.js:4:10,13: number Found 1 error

Ah, I see what you mean now with the type annotations. It looks like they require the jsx transpiler if you use them. Still, flow isn't doing the transcoding, just the static analysis part. I wish the type annotations could have been in the form of jsdoc-style comments though.
Post reply on HN