Flow engineers communicated a few months back to the community saying that they do care, they just were a small team working on the project and had pressing issues at FB to solve first. They mentioned that Flow was really slow for the large-scale projects that existed at FB and so performance was the immediate concern and that ate a year of time after they open sourced the project.

Sounds like it's on life support.

Nobody should be using Flow.

This really depends on what you care about. Flow is much better at ensuring type safety in your code while TypeScript has some pretty glaring holes in this respect. In particular, TypeScript allows covariant assignment and param passing which makes it really easy to write unsafe code.

The covariant param passing was fixed some time ago with the (now on-by-default) `strictFunctionTypes` option. Eg `function f(cb: (_: Animal) => void) { cb(new Dog()); }` can no longer be used as `function takes_cat(_: Cat) { } f(takes_cat);`

Assignment is still there though (ie you can still assign a `Cat[]` to an `Animal[]` and push a `new Dog()` into it).

I believe that `strictFunctionTypes` only applies to callbacks. TypeScript is okay with the following code even with that option turned on:

  class Animal {}
  class Cat extends Animal { meow() {} }
  class Dog extends Animal { woof() {} }

  function foo(animals: Animal[]) {
    animals.push(new Dog)
  }

  const cats: Cat[] = [new Cat];

  foo(cats);

https://www.typescriptlang.org/play/#code/MYGwhgzhAECCB2BLAt...

Your example is identical to the case I covered in the second paragraph of my comment. ie your code compiles because it is legal to assign a `Cat[]` to an `Animal[]`, as I said.

When you mentioned "covariant param passing" I assumed you were referring to the long-lasting issue about callbacks, hence my original comment mentioning that that issue has been fixed. It's not useful to differentiate between "assigning a value to a variable of a certain type" and "passing a value to a function parameter of a certain type" because those are identical.

I'd bet Flow is basically being replaced by ReasonML at Facebook[1]. Bolting a sound typesystem onto Javascript is really hard, and Flow is making a truly valiant effort, but it seems to have stalled out. Instead, ReasonML is based on starting from a "cleaned up" semantics and type system, then translating it into raw Javascript. This avoids all the weird edge cases and type inference problems one runs into when trying to use Flow[2].

(I don't ever have to have any `any` in my ReasonML code, but it was unavoidable with Flow.)

1. https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

2. https://github.com/facebook/flow/issues?utf8=&q=is%3Aissue+i...

The way the team communicates with the community is sometimes frustrating. Also, a lot of the decision-making (especially around React/JSX typing) happens behind closed doors, with little to no explanation as to why they were made.