5 ms·

I was a Flow holdout for the longest time. TypeScript's support for discriminated unions is one of the things which finally won me over. Super glad to see it be

I was a Flow holdout for the longest time. TypeScript's support for discriminated unions is one of the things which finally won me over. Super glad to see it being improved upon here.

gherkinnn 5y ago
As somebody who never worked with Flow but loves TS, what does Flow offer that the latter can’t do?
- GeZe 5y ago
  Another example would be the difference between their enum features: https://medium.com/flow-type/typescript-enums-vs-flow-enums-83da2ca4a9b4 https://medium.com/flow-type/typescript-enums-vs-flow-enums-... "TypeScript Enums vs. Flow Enums"
- nsonha 5y ago
  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.
  - GeZe 5y ago
    FYI, it would not be accurate to say that "The Flow people moved on to ReScript".
- eyelidlessness 5y ago
  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.
- inbx0 5y ago
  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 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 :)
  - moonchrome 5y ago
    >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.
    - wk_end 5y ago
      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.
- azangru 5y ago
  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.
  - johnfn 5y ago
    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.
    - azangru 5y ago
      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.
      - Zababa 5y ago
        Same thing here, though we use TS in a pretty specific way.
      - MrPatan 5y ago
        Same here, usually after rebuilding linked packages.
GeZe 5y ago
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/ https://flow.org/blog/2015/07/03/Disjoint-Unions/, TypeScript's announcement in August 2016: https://devblogs.microsoft.com/typescript/announcing-typescript-2-0-rc-2/ 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/#0C4TwDgpgBAggxsAlgewHZQLwCgq6gHygG8oBrRVAEwC4oByGOgGijAEMQAbZNmqVAK4BbAEYQATlAC+OPIRLkqtOgCFmrDt160AzsHEUA5tIDcWLADMBqBCnQWAjAAYAFG1tpa8JGgCUxWVxECyg3D1QAOkVKTAwMekZ-IkC8XHcfSPYuHkoI4GQAMUQADwhKF18zVJlU4ND0uyiKGLj41ToklNSGtAisrVz8gFUwSHEAYTYdCAqqvBkZS2twqEcHMIyvcM7akI3G6Ni2xIDU1Lg0PWJ+nKlMKB7UObONbN48wpKy2ZSavDr9r1Dq16Godi8oBdUFciDdeHd4o9nmc4YNkCMxpNpj9qlhFlYbBlVg4AEyA1BbDLg3A6ADuiGAcAAFvVwk0qNSznAptAGHRqF0IY8+poch8iqVypVBS8ROIIGxSMjzjzQfyZWdhaiPhiJFiZtKIWc5QqlRrKBALGwBJxgAKjd02aiTLgAPSu-gQABuEl+eKAA https://flow.org/try/#0C4TwDgpgBAggxsAlgewHZQLwCgq6gHygG8oBr...
symlinkk 5y ago
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.
- inbx0 5y ago
  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.

I was a Flow holdout for the longest time. TypeScript's support for discriminated unions is one of the things which finally won me over. Super glad to see it being improved upon here.

gherkinnn 5y ago

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

GeZe 5y ago
Another example would be the difference between their enum features: https://medium.com/flow-type/typescript-enums-vs-flow-enums-83da2ca4a9b4 https://medium.com/flow-type/typescript-enums-vs-flow-enums-... "TypeScript Enums vs. Flow Enums"
nsonha 5y ago
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.
- GeZe 5y ago
  FYI, it would not be accurate to say that "The Flow people moved on to ReScript".
eyelidlessness 5y ago
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.
inbx0 5y ago
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 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 :)
- moonchrome 5y ago
  >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.
  - wk_end 5y ago
    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.
azangru 5y ago
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.
- johnfn 5y ago
  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.
  - azangru 5y ago
    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.
    - Zababa 5y ago
      Same thing here, though we use TS in a pretty specific way.
    - MrPatan 5y ago
      Same here, usually after rebuilding linked packages.

GeZe 5y ago

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/ https://flow.org/blog/2015/07/03/Disjoint-Unions/, TypeScript's announcement in August 2016: https://devblogs.microsoft.com/typescript/announcing-typescript-2-0-rc-2/ 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/#0C4TwDgpgBAggxsAlgewHZQLwCgq6gHygG8oBrRVAEwC4oByGOgGijAEMQAbZNmqVAK4BbAEYQATlAC+OPIRLkqtOgCFmrDt160AzsHEUA5tIDcWLADMBqBCnQWAjAAYAFG1tpa8JGgCUxWVxECyg3D1QAOkVKTAwMekZ-IkC8XHcfSPYuHkoI4GQAMUQADwhKF18zVJlU4ND0uyiKGLj41ToklNSGtAisrVz8gFUwSHEAYTYdCAqqvBkZS2twqEcHMIyvcM7akI3G6Ni2xIDU1Lg0PWJ+nKlMKB7UObONbN48wpKy2ZSavDr9r1Dq16Godi8oBdUFciDdeHd4o9nmc4YNkCMxpNpj9qlhFlYbBlVg4AEyA1BbDLg3A6ADuiGAcAAFvVwk0qNSznAptAGHRqF0IY8+poch8iqVypVBS8ROIIGxSMjzjzQfyZWdhaiPhiJFiZtKIWc5QqlRrKBALGwBJxgAKjd02aiTLgAPSu-gQABuEl+eKAA https://flow.org/try/#0C4TwDgpgBAggxsAlgewHZQLwCgq6gHygG8oBr...

symlinkk 5y ago

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.

inbx0 5y ago
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.