Interesting move. If major projects within Facebook are migrating away it seems pretty likely that Flow is on the way out.
Which I think would be a good thing, it seems like a lot of projects and libraries haven't fully embraced either because it's unclear which to choose. In this case I don't think the "competition makes them better" aspect outweighs the downsides of having a fragmented community.
There was a time when TypeScript was woefully incomplete when compared with FlowType. When I first had to choose between them, the thing that sold FlowType to me was how it handled null checking, but I was also impressed with the rich type system with advanced type inference.
Then of course, TypeScript greatly improved and added many of those features. The Flow type inference engine is probably still more advanced, but TypeScript does good enough, and has good developer ergonomics all across the board. Hopefully Flow improved since I last used it but if not it regularly ate tons of memory, was difficult to configure, and had poor IDE integration. So in the modern TypeScript world it's hard to choose Flow despite it's potential advantages, imo.
So, I was one of (or I suppose the only...) person in the linked issue arguing that competition is useful, and that it makes sense for Facebook's products to be tied into the same ecosystem.
As others have mentioned, when Flow was first launched, TS had an extremely limited type system (e.g. no null checking, no union types). Of course this has improved a lot over time, as the two have converged, but there's still a long way to go for either project to allow JS reach the level of correctness and expressiveness of, say, OCaml or Haskell.
Flow has consistently for the past few years been bringing new ideas to the table from this algebraic data types background, which often have ended up proving to be good ideas, and are in various stages of trickling down to TS.
I worry that if the ecosystem becomes completely dominated by TS, the overall focus will end up back where TS started: rudimentary OOP inspired types, without the underlying goal of overall correctness, which Flow strives for, while TS openly eschews in favour of "pragmatism".
You can’t have the same level of correctness as ocaml if you want to maintain the compatibility with JavaScript.
Typescript type system is unsound for this reason.
You can’t have anything approaching ocaml correctness when in typescript all objects with the same shape are interchangeable.
Yeah I realise you'd never reach the same level of soundness due to the limitations of the underlying JS (although presumably you could get close with a subset?). But that's why it's an interesting challenge, and I think what Flow has shown is that it's possible to get a lot closer than had previously been imagined.
If everyone just accepted the argument 4 years ago that "JS will never be sound" then maybe today TS would still just be Java style `interface` annotations for classes. It's not like the Flow team has reached a ceiling at this point... there's still plenty on their roadmap that would continue to improve soundness and expressiveness.
> You can’t have anything approaching ocaml correctness when in typescript all objects with the same shape are interchangeable.
Could you elaborate? Flow has recently switched to exact objects by default[1], which I would have thought would be enough for a sound approach?
type A = {name: string}
type B = {name: string}
function print(obj: A) { alert(obj.name);}
let a: A = {name: “hello”};
let b: B = {name: “world”}
print(a);
print(b);
This is because of typescript structural equality and I think that the same applies to flow given your link.
Obviously if I want a function to accept an email I don’t want the same function to accept an address, but in typescript you can’t guarantee it because you have no way to get rid of structural equality as far as I understood.
I'm certainly not well versed in OCaml, but my understanding is that it is also structurally typed. This particular example would also be permitted in OCaml, correct?
IIRC, the writing was on the wall for flow these last two years. Aside from a few core users, it was never really as popular or as responsive as TypeScript was.
More a fad than the future, I suppose. But at least flow brought some valid ideas to the table, e.g., strictness.
I think that could be seen as a bit harsh, especially in light of the follow-up sentence. What Flow added to the JS ecosystem is probably the future, it's just that the implementation of that future seems to be TypeScript.
TypeScript is basically only good now because of the competition. Earlier versions were pretty darn awful.
These days, yeah, you're probably right that having only one might be better. Hopefully WebAssembly and languages running on top of it will create the awareness and competition required to keep things moving.
Which I think would be a good thing, it seems like a lot of projects and libraries haven't fully embraced either because it's unclear which to choose. In this case I don't think the "competition makes them better" aspect outweighs the downsides of having a fragmented community.