Flow also supports "discriminated unions" [0], and did so before TypeScript (Flow's announcement in July 2015: https://flow.org/blog/2015/07/03/Disjoint-Unions/, TypeScript's announcement in August 2016: https://devblogs.microsoft.com/typescript/announcing-typescr...), though it doesn't yet support destructuring the "kind" field as was just added to TypeScript.

[0] https://flow.org/try/#0C4TwDgpgBAggxsAlgewHZQLwCgq6gHygG8oBr...

As somebody who never worked with Flow but loves TS, what does Flow offer that the latter can’t do?

1. And biggest for me: Exact types

    function x(y: {
      foo: number,
      bar?: number
    }) {}

    const y = {
      foo: 1,
      baar: 2, // typo
    }
    x(y)

The above is caught in Flow when exact types are enabled but not in TS.

TS issue https://github.com/microsoft/TypeScript/issues/12936

TS has a concept of "freshness" which catches some of these mistakes when you construct y right in the arguments of x, but it gets easily broken by accident and without a warning.

2. Nominal types, so you can have for example "Id" type that is a number but not to be mixed with other numbers, you can't just call a function that expects an Id with literal 42. Classes are nominal too, which I think is a solid choise.

3. Type variance & related safeguards

    function x(y: {
      foo: string | number
    }) {
      y.foo = 1
    } 
    const y: {
      foo: string
    } = {foo: 'a'} 
    x(y) 
    y.foo.toUpperCase()

Caught by Flow but not TS.

4. Local call site type inference of function argument types, so you can have some helper functions within a file that you don't need to explicitly annotate, and Flow will happily infer types based on how you call it.

5. Performance has gotten prerty good with recent versions, to the point where I suspect it's faster than TS. I don't have any hard data on this though.

Even though in many many ways Flow is worse than TS, we have still stuck with it, and that's only like 80% because it'd be s huge undertaking to make the switch. 20% is because some of these features are actually nice :)

I would also like nominal types in TypeScript, but one issue is that it might open a can of worms that is antithetical to one of TypeScript’s main design goals: that a change in the typing of a program should not be able to modify behavior.

If you add nominal types, some people might expect them to be boxed, and thus be able to reflect on types at runtime. So I assume that TypeScript maintainers have made a design decision that users should have to “self-box” nominal types.

>2. Nominal types, so you can have for example "Id" type that is a number but not to be mixed with other numbers, you can't just call a function that expects an Id with literal 42. Classes are nominal too, which I think is a solid choise.

Structural typing is one of the best features of TS in my opinion, I like it in general but it's a better fit for JS ecosystem.

Structural typing is a sane default in JS land, but there are times that you really really want nominal typing and its complete absence from TS kind of hurts.

FWIW, io-ts offers this via its “userland” implementation of branded types.

for what it's worth you can totally fake nominal typing in a hacky way through a sort of shiboleth key. You say "this type has `____type: 'foo'`, and on constructions of the object you just cast (or hell, just put the key in!), and you're off to the races.

This is far from perfect, but when you're working with very tricky code and want to be sure, you at least have the option

Yeah, for modeling with types, you frequently want nominal types (e.g. you want to make sure that a certain types always means “the data has passed through such and such a function). Flow’s combination of structural and nominal types seems better to me than TS’s pure structural system.

I worked on a project that used used Flow 3 years or so ago. Unless something has changed since then, it was crazy fast. It took a couple of seconds from typing a command in the console to type-check the project to getting the results; whereas running tsc on a project I am working on now takes dozens of seconds to complete. This is my deepest regret of leaving Flow.

Hmm, TS is super fast today for me, at least in all the cases that matter for me. I rarely run a full project typecheck because I can trust my IDE to show me errors instantly.

Speaking of IDEs (well, VSCode), one minor annoyance is that I have to manually restart the typescript language server from time to time; otherwise VSCode doesn't pick up the types properly. Don't know which part of the toolchain is to blame for this.

Same here, usually after rebuilding linked packages.

Same thing here, though we use TS in a pretty specific way.

Another example would be the difference between their enum features: https://medium.com/flow-type/typescript-enums-vs-flow-enums-... "TypeScript Enums vs. Flow Enums"

Nominal/opaque primitive types. You “can” do it with hacks but it’s some kind of a fib and depending on approach it’s less type safe.

it has some nice features that ts doesn't have: opaque types (can be done by nominal tying in ts). More stringent JSX, but only slightly.

I think that's it these days. Flow used to have (slightly) more features but now TS has way more already and even more to come. The Flow people moved on to Recript, or whatever name they call it these days.

FYI, it would not be accurate to say that "The Flow people moved on to ReScript".

Flow feels pretty dead. The VSCode extension is broken in major ways and hasn’t gotten a major update in years. The only mainstream editor that fully supports it is IntelliJ.

The extension has picked up some attention from the core team, ever since FB retired their Nuclide tool for Atom. Not saying that the extension is perfect, but AFAIK most features come through LSP and are added to the Flow server and should pretty much be just picked up by the extension now that the LSP wiring is done. So apart from bugfixes and other small stuff, I don't know what kind of major updates you are expecting to the thing.