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

171–180 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#171

Post by denizozger »

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…

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.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#173

Post by Havvy »

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…

There's Sweet.js if you want macros.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#174

Post by Havvy »

callum85 wrote: post #142
Shizka wrote: post #132

Earlier quoted context omitted.

I've had the exact same concerns as the person you replied to. I just want to make sure since the title differs from the one you stated. Is this the book you were talking about: http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... And how/why did the book improve your opinion about the language?

It's an opinionated book that sets out a subset of JavaScript that you should use, avoiding all the 'bad parts'. This subset is what tools like JSLint and JSHint were designed to promote - they flag you up if you use a bad part. It's a seminal work. These days I find some of its rules a little dogmatic (for instance I like the 'new' keyword now), but I'm glad I went through a phase of sticking to it relgiously for a…

But `new` is a bad part. Just an optimized bad part... You could replace every usage of it with `var instance = Object.create(Ctor.prototype);` (and change every `this` to `instance` in your code), and actually explicitly return `instance` -- and then never use `new` again. Your code will become more readable to boot, as there is less action at a distance.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#175

Post by dangoor »

slackstation wrote: post #98

I wonder, how does this compare to Google's Dart.js? Like Dart, it introduces a type system into JS and like Dart, it requires a compile step between Flow code and JS that will run in a browser. What does Flow do differently than Dart?

Dart is a different language with different semantics. It is not the same as JS.

Flow starts with JS and adds a static type system (with attempts to infer types directly from the code). With the exception of the type annotations, Flow is JavaScript. Dart is not JavaScript.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#176

Post by arjie »

Touche wrote: post #140
arjie wrote: post #106

Earlier quoted context omitted.

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

I'm not sure if what you are describing is that realistic. A function that is used in some weird incorrect way that it won't get caught in development, QA or unit testing? Perhaps that can happen, but it's not been my experience. I use assertions liberally; they are especially helpful when refactoring and trying to figure out all of the dependent code that needs to be updated. Sure it's less certain than what you get…

The point is that you substitute the extra testing and QA with types. The assertion doesn't guarantee type correctness, so you test that function and downstream functions. That's extra code burden. Instead, you could have type checking.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#177

Post by eklavya »

krapp wrote: post #164
aliakhtar wrote: post #141

Earlier quoted context omitted.

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

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, you CAN write anything you want. How to translate that to JS is the compiler's job, you need not care.

Edit: what would you say to this - http://www.scala-js.org ?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#178

Post by muglug »

Ixiaus wrote: post #169
muglug wrote: post #123

Earlier quoted context omitted.

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

To be specific, I was talking only of a specific sort of errors that the JIT compiler allows e.g. applying numerical operators to strings, or combinations of string and int.

Issues with null are much more common.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#179

Post by aaronem »

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…

Industry vs. academia in two comments. Well done, the pair of you. Now stop it.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#180

Post by dragonwriter »

krapp wrote: post #164
aliakhtar wrote: post #141

Earlier quoted context omitted.

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

> 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.

Haskell is type safe, but the runtime doesn't enforce the rules, the compiler does -- the runtime, AFAIK, is no more typesafe than JS, all the typesafety comes from compilation that rejects code that isn't well typed.

So I don't see why something with a compiler that emits JS can't be just as typesafe.

Post reply on HN