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 something I rejoice about. Javascript is like anti-Batman: a language we all deserve, but not one we need.

I'm interested in who is the driving force behind this open source change in Facebook, I don't recall facebook in behaving these way 4 years ago.

Can anyone find anything on a policy change that happened? They really turned around.

"...on the web language of the past, which we are unfortunately stuck with for the foreseeable future: JavaScript" might have been a better summation of the current (rather dismal) state of affairs with regard to web scripting.

It solves not having to write a bunch of tests that can trivially be caught by a program and never having to update or maintain those tests. It hits every code path automatically, you don't have to think of cases to try to hit edge cases.

- 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 opinionated in that it enforces checks that rule out code that is legal but not likely intended in JS (an opinin I agree with).

Yes - it is possible to write tests and get good coverage and not use those tools - however static analysis can be very valuable in finding errors early. While I'm not sure I'd bother with explicit typing in this in smaller projects from the examples and unit tests it looks like it could find errors people would not easily notice otherwise. (Think JSHint, on steroids).

That said, only time will tell how good the implementation will really get in understanding your code.

The (supposed) need to have "good code coverage" is itself a problem I'd like solved.

This tool claims it can do advanced inference. If it were possible to hook it up to an editor or IDE to analyse existing untyped js in this way it could be invaluable.

Typescript (from MS) sounds a lot like what you describe - it doesn't change Javascript, it just adds types to it (and makes some ES6 features available), and it puts a lot of work into playing nice with the wider JS ecosystem (e.g. via the definitelytyped project, which integrates type definitions for most popular "third-party" javascript libraries).

> That said, I am curious what solutions this solves that isn't already solved by enforcing good code coverage. Full disclaimer, the largest js projects I've worked on were in the tens of thousands of lines, not hundreds of thousands, but type checking just seemed completely unnecessary provided a good coding guide and test coverage were maintained and enforced.

Perfect testing can do everything a type system can. But a type system can do it with less programmer effort, much lower maintenance overhead, and in a standard form that makes it easier to maintain. So you can do the same thing but cheaper - or, more realistically for how software is developed in most companies, you can get better reliability for the same engineering budget.

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

> code intelligence, which aids code maintenance, navigation, transformation, and optimization

I suspect that for facebook, this could be just as important, if not more so, than code quality benefits.

Promise<A,E> -> ((A -> (Promise<B,F> | B)),(E -> (Promise<C,G> | C))) -> Promise<B|C,E|G|C>

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 new value, or a Promise over a new value and its own type of error is returned.

Now, if the `reject` handler is executed the error is unwrapped and either a new value, or a promise over a new value or a new error is returned.

This is quite simple and easy to use because it behaves like try/catch in the dynamic type system of JS with recursive unwrapping - however it is challenging to reason about when you're starting to type code and you want to actually have correct type information with promises.

Static languages generally approach these problems with pattern matching on the type - in JS that's not common nor is it feasible at runtime - you just expect a value of a certain type. When I implemented promises in another language (swift) this was a lot of fun to work through and not very trivial - if their compiler cna do this I'd be very impressed.

Promises are just one example.

Anyway - this looks cool. I definitely agree that full sum types would've made more sense - having explicit nullables is usually a smell (like in C#).

    case mx of Just x -> f(x)

    if (x != null){ f(x) }

Haskell-style sum types are a generic type with multiple values describing the alternatives.

Since the goal of Flow is to typecheck existing JS semantics, the addition of wrapper types and objects to support such sum types makes very little sense while the addition of "anonymous" union types makes a lot of sense. Dialyzer took the exact same path (except even more so as its type unions can contain values) as it tried to encode Erlang's existing semantics.

I missed the part about sum types!

My god this is perfect

- Has other comments have said: TypeScript is getting (already in master branch) union types.

- Support for JSX isn't really a huge deal.

- Windows support will probably come - it's an open source library. I hope it's not the OCAML tooling.

You make some great points about generics and using their own type system instead of TS, especially since TS has investments from both Microsoft and Google (with AtScript which supersets it).

They state they use a model like Hack - and the repo also looks this way but I'm also curious, it looks like a very peculiar choice.

http://flowtype.org/docs/classes.html#polymorphic-classes

http://flowtype.org/docs/functions.html#polymorphic-function...

For workflow, check out: http://flowtype.org/docs/getting-started.html#_

I see some mentions of import in the tests and the grammar: https://github.com/facebook/flow/search?utf8=%E2%9C%93&q=imp...

Then perhaps you are understating the importance of software correctness. While type systems can be an almost religious topic, the benefits of type checking are real -- a whole class of bugs to disregard, less testing code, and a more maintainable codebase for other developers. Moreover, for languages with ADTs and exhaustive type-checking, you are forced to reason about boundary and error conditions. All of which leads to higher quality software, at the minimal cost of up-front work when designing your types and fixing what the compiler/checker says.

> type related errors are usually easy to find and fix and have rarely if ever been the root cause of our most difficult problems.

Type related errors may be easy to diagnose and fix -- although by definition, in the absence of type-checking, type errors are only so after the fact, eg after causing a crash. Hence the utility of type checkers, especially if it means fewer avoidable errors appearing in production.

> Dynamic type checking and implicit conversion is one of the more powerful features of JavaScript and certainly no less prone to error or counter-productive than type-casting, making variadic functions or class templates are in other languages.

Type checking doesn't diminish the usefulness/convenience of dynamic languages, but IMO lends more weight to the benefits of strongly static languages -- benefits which are negated by the abuse of "features" such as typecasting or variadic functions.

There are other issues as well, JavaScript doesn't check function arity on function calls (the arguments not supplied just get the "undefined" value), control structures do not introduce a new lexical scope etc.

We've had plenty of other bugs in the past months that tooks hours to track down but would have been caught in seconds in a sensible language. A lot of them won't be caught by flow either, unfortunately. What I really want is for operations like key lookup to fail instead of just returning me gibberish.

Typecasting is at least explicit. In js every single operation is a timebomb.

In a language without a strong type system you rarely appreciate quite how many of your invariants could be lifted into the type system. When I wrote Python most of my errors didn't seem like type errors (e.g. I remember forgetting to close a connection and so leaking connections), but now that I write Scala I can see how I'd structure my program using types so that that would be a type error (I'd use monads to compose the idea of an operation that uses a connection, and then execute them in one place).

(Python now has an ad-hoc fix for this specific problem in the form of the "with" statement, just as 3.4 adds an ad-hoc fix for the proliferation of different ways of doing async calls. But a good type system is a general solution to both these problems and more).

> Dynamic type checking and implicit conversion is one of the more powerful features of JavaScript

In a strongly typed language you can do this in a controlled way; it can be part of the language, and can apply equally well to user-defined structures. Whereas with Javascript you're stuck with those implicit conversions built into the language, and if you want to convert e.g. an address datatype, you're out of luck.

> certainly no less prone to error or counter-productive than type-casting, making variadic functions or class templates are in other languages.

Then use a language that doesn't have those problems either. There are good languages out there - if Scala isn't for you then how about OCaml or Haskell?

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.

    function length(x) {
      return x.length;
    }

    length(null);

TypeScript doesn't have that concept, although it's been suggested by the community more than once.

Besides perhaps the extra 'compile' time added to do both translation with TypeScript and then static analysis with Flow. Both tools have their advantages and disadvantages.

May as well throw in a linting tool as well..

JavaScript has a weird ecosystem where it is extremely helpful to have all of your tools in the same language. browser-based IDEs, Node, portability, etc, and just one fewer runtime to juggle.

Same reasons why closure is awkward as a Java program.

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?

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

The code has a build step - yes. You will not be able to run this code without a step. It could be awesome if they allowed annotations in comments like other tools do - there is a GH issue on that and it looks like it should be possible https://github.com/facebook/flow/blob/master/src/typing/comm...

http://flowtype.org/docs/existing.html#_http://flowtype.org/docs/running.html#_

I think Dart seems to be a great language and IE, Firefox and Safari should have implemented it years ago, but they didn't. Now I think TypeScript is a great addition to javascript and I hope they build it into the browsers but I suppose they won't (maybe EcmaScript 7 will have some parts of TypeScript in it, or parts from AtScript from Google).

By the way, you probably still want minification and concateneted files when you create js from other languages. That stops me from using them, I would have many levels of tools between my source code and the production code.

People will tell me that it is a good language if you know how to use it, comparing javascript mastery to C mastery in a sense. I think there lies the problem.

Also, some techniques from Typed Racket (occurrence typing): http://www.ccs.neu.edu/racket/pubs/popl08-thf.pdf

Many other papers have influenced the design in some way or the other. For example, Abadi/Cardelli's theory of objects.

http://learnyouahaskell.com/

The React.js team has been explicit about the library being GCC advanced mode compatible, so they certainly have awareness of its capabilities. Whether they are using them together internally or they use a different solution for tree shaking et al is another question.

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.

Also, if you're code is implicitly statically typed (as checked by Flow) you will likely hit all the right optimizations in the underlying JavaScript VM.

After investigating this thought, it looks like this already at the top of the list for future plans for Flow:

http://flowtype.org/docs/coming-soon.html

It'd be quite possible to add the ability to output these annotations to the CoffeeScript compiler itself though. Could be an interesting fork.

You can probably hack it using the backtick operator though.

    `function foo(x: string, y: number): string {`
    x.length * y
    `}`

The problem was that there were two identical comments, the software killed one as a dupe, and avik deleted the other one. The software tries to fix this very scenario—it normally would have automatically unkilled the remaining member of the pair. But there are some corner cases where that doesn't work, and avik seems to have outsmarted it.

We'll take a look and try to fix the fix.

I'm surprised that they don't seem to have launched with a public editor plugin and that the documentation doesn't seem to mention it.

If CoffeeScript is to support these annotations one day - it would require the CoffeeScript compiler to support them itself in order to generate correct annotated JavaScript for Flow.

http://en.wikipedia.org/wiki/Type_system#Static_type-checkin...

Even if that wasn't the case, their design just avoids the issue by not trying to do any typecast, ever.