TS bolts on a straightforward nominative type system without type unions (or non-nullable types), so it can't handle a variable typed as `number | string`, it'll immediately drop down to `any`. That is, flow aims to remain useful in the face of more JS idioms. It won't make a difference between nullable and non-nullable either, so AFAIK

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

    length(null);

can never be a compile-time error in typescript.

Union types are present in the master branch of the TS compiler. The compiler also uses instanceof and typeof === ... to reduce the range of types inside a branch, similar to Flow.

Due to ship with TypeScript 1.4 - see recent blog post: http://blogs.msdn.com/b/typescript/archive/2014/11/18/what-s...

Yep, here's some related discussion: https://github.com/Microsoft/TypeScript/issues/185

tl;dr: they want to support both of those features, the question is what syntax to use and how to introduce those features into the existing ecosystem.

One major difference is the null checking. From what it looks like, they've added an additional type, "maybe", that represents a possibly-null object.

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

Here is some interesting discussion on that aspect of the typesystem: https://github.com/Microsoft/TypeScript/issues/14 It also discusses Flow from 2 months ago (from a now removed video)

No, instead of complaining about 'x' having the 'any' type, Flow will actually try to infer a static type for 'x'. So in the best case there would be no errors (and in the worst case there would be actual errors to fix).

Is there any reason we cannot use both TypeScript and Flow.

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