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

221–230 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#221

Post by xixixao »

paulddraper wrote: post #189
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…

"better step in the right direction than the types of tools MS and Google have been putting out" The Google Closure Compiler ( https://developers.google.com/closure/compiler/ ) has been around for years and years. It does everything you mentioned (100% optional type annotations, type inference), plus more (dead code removal, inlining, compiler-time constants).

Google Closure: function hello(a){alert("Hello, "+a)}hello(3); Compilation was a success! No warnings No errors

+ it's not incremental hence unusably slow, requires Java. No, Closure is not the same as Flow even from a brief look at both.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#222

Post by _pmf_ »

spion wrote: post #136
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…

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…

> ES6 adds lambdas, destructing assignment, default/rest/ spread arguments and template strings - all of those reduce verbosity.

Yes. But the existing warts do not go away (and neither will they ever, due to the need for backwards compatibility).

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#223

Post by realusername »

alexjeffrey wrote: post #210
spion wrote: 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…

a cryptographically secure pseudorandom number generator would be nice, too.

Isn't crypto.getRandomValues created just for this purpose ?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#224

Post by weavie »

ep103 wrote: post #103
inglor wrote: post #78

Earlier quoted context omitted.

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

Absolutely. I used to use hungarian notation in a static language because I was so scared of getting the wrong type. It was a huge revelation that actually this never happens.

However, whilst I never hit on basic type errors such as passing a string when I need an int - I regularly come across object type errors. I'll pass an object with a project_id property to a method that actually expects an id property. Not sure if flow can handle these - if it could it would be pretty amazing.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#225

Post by _pmf_ »

krapp wrote: post #185
eklavya wrote: post #177

Earlier quoted context omitted.

Hmm, so assembly code doesn't have any type safety or high level features. So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right? What a load of crap and the op is down voted!!! You are writing java and barring some features like multi-threading,…

>So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right? Javascript is not the equivalent of assembly. Javascript is, itself, a higher-level language. You're talking about translating from one high-level language to another, and expecting the inte…

> You're talking about translating from one high-level language to another, and expecting the interpreter for the latter to care anything about the rules of the former.

Yes; but the Closure compiler knows about the semantics of JS and generates a shitload of disgusting low-level wrappers and checks that implement the retarded JS semantics. You're right in that there are cases where this breaks down, but Closure is not really a high-level-language to high-level-language compiler. The JS output is not in any way human readable (look, for example, at http://de.indeed.com/s/8a9f5dc/jobsearch-all-compiled_de.js).

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#226

Post by ajuc »

ep103 wrote: post #103
inglor wrote: post #78

Earlier quoted context omitted.

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

I do hobby level small js projects, I make type errors quite often, but they are easily found the moment I run the tests/the app. I would prefer to find them at compile time, but it's not a big deal.

Interstingly it's almost always the same kind of type error- accessing nested maps/arrays and forgetting to go deep enough before I call some method on the elements in that collection.

I can't remember one example of type error where I intended to call method on MyClassA and ended up trying to call it on MyClassB. But that may be the effect of my coding style (I'm not big fan of class hierarchies in js).

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#227

Post by swah »

kulkarnic wrote: post #127
DigitalSea wrote: post #39

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…

From http://steve-yegge.blogspot.com/2007/02/next-big-language.ht...

- Rule #1: C-like syntax

- Rule #2: Dynamic typing with optional static types

- Rule #3: Performance

- Rule #4: Tools

- Rule #5: Kitchen Sink

- Rule #6: Multi-Platform

This tool provides #2 for Javascript, the NBL.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#228

Post by barrkel »

muglug wrote: post #123
ep103 wrote: 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.

In JS, I see things like methods called with incorrect number of parameters, or wrong parameter types, on a reasonably regular basis, especially when things get refactored every now and then.

I frequently see methods incorrectly overidden. For example, the ancestor method effectively has a variadic argument list, but the descendant doesn't have as sophisticated argument handling and doesn't do the appropriate superFunc.apply(this, Array.prototype.slice.call(arguments, 0)) etc.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#229

Post by conradk »

kulkarnic wrote: post #127
DigitalSea wrote: post #39

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…

A lot of what you say is purely subjective.

I would consider C++ to be way more verbose than Javascript. Especially with ES6 coming (and things like Flow / Typescript allowing you to use ES6 today).

Weird scoping? What are you talking about here? It's not the same as other languages. That does not make it weird. When you understand how it works, it's not a problem. Use it to your advantage.

Not nice to optimize for? Javascript is fast enough for most tasks, provided you use best practices. You can even build AAA games with it nowadays, through ASM.js. I'd like to learn more about what you mean exactly when you say it's not nice to optimize for, if you have the time.

I get that Javascript has its quirks. But so do most languages. What's awesome is that JS is easy to get started with, but can be used to build complex apps (especially with things like Flow / TS). And it works everywhere. And it has an amazing ecosystem of client side and side libraries.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#230

Post by emmanueloga_ »

There's some tremendous effort being poured into making a crippled language like javascript usable, but when talking about solutions for maintainable frontend code, I'm more excited about compile-to-js languages like haxe [0], purescript [1] or ceylon [2].

The caveats I heard about transpilers often boil down to difficulty of debugging and lack of libraries. But with the amazing browser dev tools we have, debugging potential issues is not that painful. Every language compiling to js provides FFI and/or some escape hatch so you can write javascript manually, for performance tuning or for using 3rd party libs.

Even if you do write "raw" javascript, some sort of compile step is unavoidable, for running jshint, concatenating, minifying, etc. Why not walk the extra mile and use a better language?

BTW, I'm not saying a tool like this is not super-useful, specially if you already have thousands of lines of js code that you can't get rid of. Congrats to the Facebook team for the release!

0: http://haxe.org/

1: http://purescript.org/

2: http://ceylon-lang.org/

Post reply on HN