Facebook Launches Flow, Static Type Checker for JavaScript • Hacker News Board

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#191

Post by hyp0 » Wed, Nov 19, 2014, 4:26 AM UTC

avik wrote: post #160

discreteevent wrote: post #135

Earlier quoted context omitted.

The main benefit of types for me is not correctness but documentation and tooling. It's fine not to have types in code I write myself or with one or two others. But if I have to deal with a large codebase that I wasn't involved in writing then types make it so much quicker to understand. Just being able to quickly find all references to a type or all a method's call sites makes it possible to "reverse engineer" the d…

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 adopt it?

But static types can be a hard sell for JS programmers. What sort of reception has it gotten inside facebook?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#192

Post by Havvy » Wed, Nov 19, 2014, 4:31 AM UTC

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?

Flow doesn't have any semantic changes from JS, only semantic restrictions. For anything that is not types, Flow defers to JS. Dart defers to it's own specification.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#193

Post by hnriot » Wed, Nov 19, 2014, 4:43 AM UTC

aikah wrote: post #143

cdelsolar wrote: post #129

Earlier quoted context omitted.

Read the Good Parts of Javascript and get a JS linter. Javascript is a fine language if you do this.

> Javascript is a fine language if you do this. No,it's not fine, it's a horrible language,with a few good features that saves it from being a catastrophy.hence "Good Parts". Or we wouldnt be here talking about Flow,Typescript or others if the language was "fine". JS was clearly not designed for what we are making out of it today. But since there is no way around Javascript in webdev,good or bad,it doesnt even matter…

nonsense. Just because people and companies have contributed new features and capabilities to the language doesn't make your point. It's not a horrible language, any more than any language. Of course it has things that aren't ideal, but it's highly expressive and if you know what you're doing it can be elegant.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#194

Post by hyp0 » Wed, Nov 19, 2014, 6:02 AM UTC

This looks great, in typesystem/tooling/presentation, and sounds perfect for facebook; but for mainstream adoption, it needs to meet (or be closer to) the ideal of free-benefits:

(1) zero-work: works instantly with existing code and esp third party libraries; and

(2) instant-benefit: provides some compelling benefit in that zero-work case above (of course, it's OK if it provides more benefit if you do more work, adding type annotations etc).

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#195

Post by hyp0 » Wed, Nov 19, 2014, 6:05 AM UTC

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

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#196

Post by acjohnson55 » Wed, Nov 19, 2014, 6:06 AM UTC

peq wrote: post #148

inglor wrote: post #44

Earlier quoted context omitted.

Strongly typed JS is actually pretty hard - probably not by Haskell and Scala standards - but if you take promises for example the signature of `then` is: Promise -> ((A -> (Promise | B)),(E -> (Promise | C))) -> Promise That is - a promise's then - takes the promise (as this) and executes either a `.then` fulfillment handler or a catch handler. If the `fulfill` handler executes the value is unwrapped and either a ne…

I think sometimes types lead to simpler designs. For example why can't "then" just have the following type: Promise A E -> (A -> A') -> (E -> E') -> Promise A' E' That would eliminate some strange corner cases and make it easier to explain the function. The special cases could just get their own functions. Real algebraic data types would probably eliminate the need for E entirely and make it even simpler.

I would argue that `then` is better thought of as:

Promise A E -> (A -> Promise A') -> (E -> Promise E') -> Promise A' E'

, with implicit boxing of bare types and thrown exceptions, as well as flattening of superfluous Promise wrappers. The `flatMap`iness of it is what really makes it interesting, in my opinion.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#197

Post by Xixi » Wed, Nov 19, 2014, 6:20 AM UTC

yazaddaruvala wrote: post #167

warfangle wrote: post #157

Earlier quoted context omitted.

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.

May I ask why? Not having parallelism seems like a net negative to me...

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#198

Post by tel » Wed, Nov 19, 2014, 6:31 AM UTC

inglor wrote: post #44

slashnull wrote: post #31

At last! This all seem extremely cool. I went straight from hacking Scala and Haskell as a hobbyist to doing (mostly) front-end JS job, and I've always found that my code, and a lot of good libraries I read, naturally emulate something close to Hindley-Milner typing, by using objects as tuples/records and arrays as (hopefully well-typed) lists, as well as the natural flexibility of objects as a poor substitute for Ei…

Strongly typed JS is actually pretty hard - probably not by Haskell and Scala standards - but if you take promises for example the signature of `then` is: Promise -> ((A -> (Promise | B)),(E -> (Promise | C))) -> Promise That is - a promise's then - takes the promise (as this) and executes either a `.then` fulfillment handler or a catch handler. If the `fulfill` handler executes the value is unwrapped and either a ne…

That's an outrageously overwrought type, though.

Let's say a promise is a thing which can either succeed or fail eventually. If it fails, it gives a type e, if it succeeds a type a

    Promise e a

Now, `then` operates on the successful result, transforming it into a new promise of a different kind. The result is a total promise of the new kind

    then :: Promise e a -> (a -> Promise e b) -> Promise e b

I'll contest now that this is sufficient. Here's what you appear to lose:

    1. No differentiation of error types
    2. No explicit annotation of the ability to 
       return constant/non-promise values
    3. No tied-in error handling

That's fine, though. First, for (1), we'll note that it ought to be easy to provide an error-mapping function. This is just a continuation which gets applied to errors upon generation (if they occur)

    mapError :: (e -> e') -> Promise e a -> Promise e' a

For (2) we'll note that it's always possible to turn a non-promised value into a promise by returning it immediately

    pure :: a -> Promise e a

Then for (3), we can build in error catching continuations

    catch :: Promise e a -> (e -> Promise e' a) -> Promise e a

We appear to lose the ability to change the result type of the promise upon catching an error, but we can regain that by pre-composition with `then`.

So, each of these smaller types is now very nice to work with. They are equivalent in power to the fully-loaded `then` you gave, but their use is much more compartmentalized. This is how you avoid frightful types.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#199

Post by joshkpeterson » Wed, Nov 19, 2014, 6:37 AM UTC

leopoldfreeman wrote: post #181

Just tried it. Not good for projects depending heavily on 3rd party libs. I have to define all the interfaces in a 'interface file' to keep 'flow' silent. This seems an impossible job for our project.

It's the same with typescript. The community will take care of most libs over time.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#200

Post by scotth » Wed, Nov 19, 2014, 6:37 AM UTC

yazaddaruvala wrote: post #167

warfangle wrote: post #157

Earlier quoted context omitted.

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.

Honest question: How different is a web worker from an actor?