Live data from Hacker News

Facebook Launches Flow, Static Type Checker for JavaScript

code.prod.facebook.com

161–170 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#161
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'?

We actually built this because we write a lot of JavaScript at Facebook, and we need a tool like Flow. So yes, we worked on it full-time, with "funding": our developers like to move fast, Flow helps them do that.

(It's a different matter that we would have done this on our free time anyway, because it's so much fun!)

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#162

Does it support structural typing? That seems to be the strongest advantage of TypeScript.

Yes, it does. You can define object types like { x: number; y: string }, tuple types like [number, string], function types like (x:number) => string, etc.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#163

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…

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…

   JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in
You have conflated quality and popularity.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#164
post #131

Earlier quoted context omitted.

Those are features of the IDE, and of Java, certainly. But type safety doesn't really exist in javascript. Structures like interfaces and classes don't really exist. Inheritance is different. Scope is different. What you have is a javascript framework which emulates the behavior of Java to the degree that javascript permits, but can't really implement it. I'm not saying it isn't a useful tool, or that the javascript…

>type safety doesn't really exist in javascript. Structures like interfaces and classes don't really exist. Inheritance is different. Scope is different. You are not coding in javascript. You are coding in java, and the code is then converted into highly efficient javascript by a compiler. > What you have is a javascript framework which emulates the behavior of Java to the degree that javascript permits, but can't re…

I don't think you're seeing my point.

You may be coding java, but none of the tangible benefits of java over javascript actually translate, because you're actually writing javascript, with all of the warts and limitations and weirdness therein.

The javascript exported will not be truly type safe, because javascript is not, and cannot be. It may appear to act like it, within the context of the code when run as predicted, but this isn't the same thing as an actual strict language in a runtime which expects and enforces those rules. Highly efficient? Doubtless. Optimized to avoid as many pitfalls of the language as possible? Certainly. But anything more capable than bog-standard javascript? No. Because it can't be.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#165

Make sure to checkout http://ternjs.net/ too. It does not have types validation I believe, but it does many other things and in combination with eslint allows catching most errors before packaging. Tern.js actually detect types, and may be it would be possible for eslint to incorporate it somehow to detect invalid use of types. One big ternjs plus for me is the fact that tern.js knows about require.js modules and can…

Thanks, I remember seeing this a while back but didn't realise it was RequireJS-aware. The demo is pretty great.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#166
post #139

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…

> JS the language of the future? [...]I can certainly see being stuck with Javascript I think we all agree. JS has very ugly things, but it isn't going anywhere for the forseeeable future. If we're going to use for at least a few more years, I'd applaud anyone making better tools and rejoice when I see better frameworks and easier to use libraries. Now by the time alternatives to javascript become viable, we might ha…

It's already getting more enjoyable to me. Things like .forEach and => mean I can write really nice code.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#167
post #136

Earlier quoted context omitted.

ES6 adds lambdas, destructing assignment, default/rest/ spread arguments and template strings - all of those reduce verbosity. And there is `let` which has a "normal" scope, although I'm not really sure it needs that. Additionally, generators let you use normal control flow constructs for IO, if you prefer that to FP. While its no Haskell, it certainly isn't much more verbose than other dynamic languages anymore. And…

We've got parallelism in the browser (sorta) with webworkers.

I'm actually glad there isn't parallelism (well threads/actors/tasks).

I'd go so far as to consider it a feature.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#168
post #52
post #46

Earlier quoted context omitted.

It's hard for me to give appreciation but while Google have traditionally been tech leaders in web technologies: Facebook are doing really awesome stuff lately. It's not just React and this - it's also FLUX, HHVM, Hack, Haxl (Their Haskell libraries), contributing to writing a spec for PHP and other ventures. I'm interested in who is the driving force behind this open source change in Facebook, I don't recall faceboo…

Thanks for the kind words. For context, I'm an HHVM alum who has been at Facebook for almost six years now (wow time flies). From my point of view, most of what has changed is resources and the immediacy of our survival-level concerns. Four years ago Google had declared nuclear war on us, we had far fewer users, we were not profitable, there were constant fires to put out with basic production operations stuff we've…

Thank you, so very very much, for HHVM. Between HHVM, Hack, and now Flow, I can write software using the languages I use most often but gain the benefits of better tooling.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#169
post #123
post #103

Earlier quoted context omitted.

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 flexibi…

In the large multi-contributor dynamically-typed codebases I've dealt with, type errors are very rare.

I don't think you understand what "type errors" means if you are making that assertion; or your multi-contributor codebase has such excellent test coverage that your tests are doing for you what a modern type system can do for you.

In a dynamically-typed codebase, it's near impossible to have rare type-error occurrence because you're off-loading the type system into into the programmers head (which is subject to human fallibility - even when countered with excellent unit testing!)

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#170
post #118

Earlier quoted context omitted.

I'd like to argue from a Haskell backend perspective that monad transformers deserve exactly the complexity they expose. They give you a handle to factor side effects in sensible ways and to express that code requires exactly some set of effects and no others. It is not always clear how to factor code which does not have this rigor into effect-typed form. It can be extraordinarily difficult to recognize what effects…

... said the monk, sitting cross-legged with an air of zen inner peace ; ) I think it all boils down to considerations of idealism vs. realism, in the end, and yes, I have to admit, I managed to get a sort of big picture understanding of Yesod and its ORM, and it's definitely a cool design. Can't say I know as much about Happstack, but the hello worlds were smaller. And the authors didn't have to invent two dependenc…

I'm not a big user of Yesod, so I can't speak too much to that, though it is notoriously difficult to get Yesod to compile unless you use Stackage.

I would say that types are really difficult to do in your head. It's tedious and error-prone. That said, the advantages are high so it's valuable, e.g. your parser combinators in PHP.

Parser combinators are actually a great example of where monad transformers shine. You can see them as nothing more than a stack of `State` atop `Maybe` which dramatically simplifies the presentation and why they work. Better, you can rip out `Maybe` and replace it with `[]` to get non-deterministic parsers "for free"—all of the code remains the same.

I actually happened to write up about this recently:

    https://gist.github.com/tel/df3fa3df530f593646a0
But yeah, gradual typing is seductive for existing codebases. You can just make the jump and beat them with hammers of frustration until the compiler gives you a thumbs up---but it's nobody's cup of tea. If you want discipline, you are far better off setting the rules from t=0 and going from there.

Let me know when you start porting to Haskell. That'll be an exciting time.

Post reply on HN