9 ms·

Flowtype is seeming more and more like the Mercurial to Typescript's git. (That is, in terms of inertia, it seems like the community has decided on a winner)

swsieber 9y ago
Indeed. And I really wish Flowtype was winning because Typescript isn't sound (sound being a real technical term when referring to static tupe systems), and Flowtype is. On the other hand, I'll take ts over js any day.
- seanmcdirmid 9y ago
  Type soundness is overblown. A type system doesn't need to be sound to be useful, and the pragmatic approach taken by TS has turned out to be really useful. (In the old days, type systems were just purely about correctness, so soundness was key, but those days are long past us, we depend on type systems for many different things now)
  - raquo 9y ago
    In my experience with TS, its unsoundness was very frustrating. If you use it as a replacement for JSDoc where type ascriptions are more like recommendations, sure, but I like to have more confidence than that in a type system. FlowType is much better in that regard. Scala.js has been the best for me so far.
    - seanmcdirmid 9y ago
      I'm much more bothered by TS's lack of separate compilation (errors tend to cascade, but this is to be expected from a structural rather than nominal type system). The killer app for type systems has always been code completion.
      - mafribe 9y ago
        has always been code completion. I disagree. Code completion is overrated and only of marginal importance in the production of high-quality code. The key advantages of types are: - Enabling ahead-of-time compilation resulting in efficient code. - Guarantees on the absence of specific classes of bugs. (This requires soundness.) - Aiding verification. Types provide a rough classification of program behaviour which drastically simplifies verification. If you don't have types, your program logic needs to make typing information explicit in assertions.
        seanmcdirmid 9y ago
        1. Nope, as proven that many people use JavaScript in the first place. 2. Type systems have always been super limited in the kinds of bugs they can eliminate, even with "soundness". 3. This sounds like a type theorists point that is completely detached from most programming experiences.
        mafribe 9y ago
        (1) I'm not sure I understand point. JS has long been without alternative, that's why JS has seen such a massive uptake. Moreover all JS alternatives, from TypeScript to Scala.js to Elm to Flow are adding types. Anyway JS's popularity is orthogonal to questions about efficient compilation. Types drastically simplify those, for you can work out at compile time how much memory needs to be allocated for each sub-expression of the program under execution. If you don't have types, you can only do that at run-time, and need extremely complicated JIT compiler technology to make this moderately performant. (2) Sure. Still extremely helpful, all the more so, the bigger the software. If you don't have types to do this, you will have to find those bugs by testing -- much more labour intensive. (3) Detached, maybe, but still true. To paraphrase Sutton's law: I'm detached from the toils of contemporary bread/butter programmers and look at verification because that's where the interesting open problems are.
    - boubiyeah 9y ago
      I have a feeling you're talking about an old version of typescript. Versions 2.2+ (currently 2.3.2) are sound (but not fully so, just like flow) with the right flag(s). Here's the description of the "strict" compiler option that goes a long way to make your program more reliable : "Enable all strict type checking options. Enabling --strict enables --noImplicitAny, --noImplicitThis, --alwaysStrict and --strictNullChecks."
      - tekacs 9y ago
        Typescript (even with all those options on) isn't even close to sound. Some of the soundness issues are by design (making directly overlayed JS code reasonable to type/interface with), some are due to 'taking too much time/design complexity if implemented'. I won't go into them one by one, but you can jump into most of the issues here to get a sense: https://github.com/Microsoft/TypeScript/issues?utf8=&q=Soundness https://github.com/Microsoft/TypeScript/issues?utf8=&q=Sound... https://github.com/Microsoft/TypeScript/issues?utf8=&q=unsound https://github.com/Microsoft/TypeScript/issues?utf8=&q=unsou... I won't take a position on the matter other than to say that it's a tricky balance and the TS team are at the very least extremely clear in saying that you should not be looking for a high degree of soundness here (JS interop is a higher priority). If those things are important, I would recommend Scala.js or PureScript or... anything more self contained (and remember that they're still ultimately dynamically typed on the JS boundary, just not inside the language). Here's the TS team explaining their position themselves: https://github.com/Microsoft/TypeScript/issues/9825#issuecomment-233843817 https://github.com/Microsoft/TypeScript/issues/9825#issuecom... https://github.com/Microsoft/TypeScript/issues/13003 https://github.com/Microsoft/TypeScript/issues/13003 (not the most cordial commenter unfortunately)
        boubiyeah 9y ago
        Oh I know! You also can't control variance and it can display bad behaviors once in a while. Overall though, getting bitten by the unsoundness is fairly rare , imo.
        tekacs 9y ago
  - bad_user 9y ago
    For anybody reading this and nodding, here are a few unsoundness samples from Typescript: https://news.ycombinator.com/item?id=14475818 https://news.ycombinator.com/item?id=14475818
- RyanCavanaugh 9y ago
  Flowtype isn't sound either. I don't know where this misapprehension comes from or why people keep repeating it; if you simply try to induce an unsoundness in Flow you'll succeed after about 30 seconds of trying. An actual sound type system built on top of regular JS would be unusable - you'd have to disallow almost everything. The language is too "dynamic" to become properly sound.
TheAceOfHearts 9y ago
I prefer Flowtype, but I definitely agree that TypeScript seems to be winning on the popularity front. One of the big problems is that flow has far fewer definition files available. Most projects don't want to support two separate type specs. Even if it didn't provide 100% compatibility, having something take you 90% of the way there would be a big improvement. But I'm still betting on flow. I like that it's supported by babel and it generally seems to be better at helping you catch bugs. @thejameskyle recently tweeted [0] a short snippet showing a great example showcasing flow. [0] https://twitter.com/thejameskyle/status/868148120504356864 https://twitter.com/thejameskyle/status/868148120504356864
- AgentME 9y ago
  Does Typescript still require you to have definitions for every library in order to use the library? One thing I love about Flow is that it doesn't have that requirement. You can start using a new library, and later on if you find that type safety in that library's exports would be useful, then you can look for or write definitions then. You're not blocked from adopting the library. I find for many of my dependencies that I use in a few spots it's not really important for me to have definitions for.
  - typebore 9y ago
    technically you do need to define at the top level, but no, not in a practical sense: declare var $: any; $( "element" ).compiler.leaves.you.alone
  - jsight 9y ago
    I don't think that Typescript ever did require that? AFAIK, it has always been possible to just declare the variable as "any" type and use it as if it were untyped.
    - neilsimp1 9y ago
      Can confirm. This has been my experience.
    - 9y ago
boubiyeah 9y ago
And for good reasons. flow started as "the better one of the two in theory" with better ideas, more strictness, way more expresiveness in its type system. But typescript took all these ideas, listened to the community and bridged the gap in features really fast, together with more stability, thus making flow pretty much obsolete. typescript is way more stable. I can take a nightly or RC version of typescript and I know it's going to work better than flow which I tried several times and always let me down. If you don't trust a type system, it's hard to justify using it at all, apart from the documentation it provides to other devs. These projects are complex, and I think only the typescript team invested enough to make it truly work.
- bad_user 9y ago
  > If you don't trust a type system, it's hard to justify using it at all, apart from the documentation it provides to other devs. 100% agree, although I have to wonder, why don't you see that Typescript is NOT a type system you can depend on. Fact of the matter is that Typescript has serious soundness issues and will always have. Those problems haven't disappeared. What this translates to in practice is that Typescript annotations are little more than documentation. And it simply doesn't compare with any sane static language where the first line of defense is the compiler.
  - Silfen 9y ago
    > Typescript annotations are little more than documentation This is true at the boundaries of your codebase, but if your application is complex enough, tsc is a life saver. Typescript saves me from bugs literally every day. Not to mention the benefits around tooling and refactoring. Agreed that there are some big footguns with respect to soundness, though.
  - resf 9y ago
    What is the practical benefit of soundness? I offer that soundness is a disease that makes programming languages far more complex than they have any right to be. A static type system exists to prevent some classes of bugs and enable code completion. However whenever "soundness" becomes a design goal, it enevitably usurps everything else (because it is an objective binary goal) and leads to languages that cease to value other things like simplicity or directness. A type system can never catch all bugs and reliable programs ultimately depend on a human being understanding and verifying the code. The most important goal - if you value reliable programs - is that the code is intelligible to people.
hamstercat 9y ago
It's pretty fun to use in React/React Native. Can't talk about Flow since I haven't tried it, but TypeScript definitely beats out plain JavaScript. What I like best is that it doesn't forces you to write your code differently than you would in JavaScript, it simply augments it with type information.
rattray 9y ago
stats to back that up: https://npm-stat.com/charts.html?package=flow-bin&package=typescript https://npm-stat.com/charts.html?package=flow-bin&package=ty... (the weekly view is easiest to parse) Looks like flow downloads have been declining week-on-week for the past 6 weeks. Note that flow is likely underrepresented, since many people install it with brew (or apt-get, or whatever).
akurilin 9y ago
Is flowtype actually getting left behind? What's the evidence for that? I'm simply curious because our team heavily invested in it over the past couple of years and I'd love to know ahead of time when it's time to jump ship.
- habitue 9y ago
  It's probably not time yet, but the winds are blowing that way so hard, I wouldn't be surprised if it becomes completely obvious in a couple years
- whatever_dude 9y ago
  It's not getting left behind, but it's as if two separate worlds exist. In the react/Facebook works, flow is the defacto default for many things.

swsieber 9y ago

Indeed. And I really wish Flowtype was winning because Typescript isn't sound (sound being a real technical term when referring to static tupe systems), and Flowtype is. On the other hand, I'll take ts over js any day.

seanmcdirmid 9y ago
Type soundness is overblown. A type system doesn't need to be sound to be useful, and the pragmatic approach taken by TS has turned out to be really useful. (In the old days, type systems were just purely about correctness, so soundness was key, but those days are long past us, we depend on type systems for many different things now)
- raquo 9y ago
  In my experience with TS, its unsoundness was very frustrating. If you use it as a replacement for JSDoc where type ascriptions are more like recommendations, sure, but I like to have more confidence than that in a type system. FlowType is much better in that regard. Scala.js has been the best for me so far.
  - seanmcdirmid 9y ago
    I'm much more bothered by TS's lack of separate compilation (errors tend to cascade, but this is to be expected from a structural rather than nominal type system). The killer app for type systems has always been code completion.
    - mafribe 9y ago
      has always been code completion. I disagree. Code completion is overrated and only of marginal importance in the production of high-quality code. The key advantages of types are: - Enabling ahead-of-time compilation resulting in efficient code. - Guarantees on the absence of specific classes of bugs. (This requires soundness.) - Aiding verification. Types provide a rough classification of program behaviour which drastically simplifies verification. If you don't have types, your program logic needs to make typing information explicit in assertions.
      - seanmcdirmid 9y ago
        1. Nope, as proven that many people use JavaScript in the first place. 2. Type systems have always been super limited in the kinds of bugs they can eliminate, even with "soundness". 3. This sounds like a type theorists point that is completely detached from most programming experiences.
        mafribe 9y ago
        (1) I'm not sure I understand point. JS has long been without alternative, that's why JS has seen such a massive uptake. Moreover all JS alternatives, from TypeScript to Scala.js to Elm to Flow are adding types. Anyway JS's popularity is orthogonal to questions about efficient compilation. Types drastically simplify those, for you can work out at compile time how much memory needs to be allocated for each sub-expression of the program under execution. If you don't have types, you can only do that at run-time, and need extremely complicated JIT compiler technology to make this moderately performant. (2) Sure. Still extremely helpful, all the more so, the bigger the software. If you don't have types to do this, you will have to find those bugs by testing -- much more labour intensive. (3) Detached, maybe, but still true. To paraphrase Sutton's law: I'm detached from the toils of contemporary bread/butter programmers and look at verification because that's where the interesting open problems are.
  - boubiyeah 9y ago
    I have a feeling you're talking about an old version of typescript. Versions 2.2+ (currently 2.3.2) are sound (but not fully so, just like flow) with the right flag(s). Here's the description of the "strict" compiler option that goes a long way to make your program more reliable : "Enable all strict type checking options. Enabling --strict enables --noImplicitAny, --noImplicitThis, --alwaysStrict and --strictNullChecks."
    - tekacs 9y ago
      Typescript (even with all those options on) isn't even close to sound. Some of the soundness issues are by design (making directly overlayed JS code reasonable to type/interface with), some are due to 'taking too much time/design complexity if implemented'. I won't go into them one by one, but you can jump into most of the issues here to get a sense: https://github.com/Microsoft/TypeScript/issues?utf8=&q=Soundness https://github.com/Microsoft/TypeScript/issues?utf8=&q=Sound... https://github.com/Microsoft/TypeScript/issues?utf8=&q=unsound https://github.com/Microsoft/TypeScript/issues?utf8=&q=unsou... I won't take a position on the matter other than to say that it's a tricky balance and the TS team are at the very least extremely clear in saying that you should not be looking for a high degree of soundness here (JS interop is a higher priority). If those things are important, I would recommend Scala.js or PureScript or... anything more self contained (and remember that they're still ultimately dynamically typed on the JS boundary, just not inside the language). Here's the TS team explaining their position themselves: https://github.com/Microsoft/TypeScript/issues/9825#issuecomment-233843817 https://github.com/Microsoft/TypeScript/issues/9825#issuecom... https://github.com/Microsoft/TypeScript/issues/13003 https://github.com/Microsoft/TypeScript/issues/13003 (not the most cordial commenter unfortunately)
      - boubiyeah 9y ago
        Oh I know! You also can't control variance and it can display bad behaviors once in a while. Overall though, getting bitten by the unsoundness is fairly rare , imo.
        tekacs 9y ago
- bad_user 9y ago
  For anybody reading this and nodding, here are a few unsoundness samples from Typescript: https://news.ycombinator.com/item?id=14475818 https://news.ycombinator.com/item?id=14475818
RyanCavanaugh 9y ago
Flowtype isn't sound either. I don't know where this misapprehension comes from or why people keep repeating it; if you simply try to induce an unsoundness in Flow you'll succeed after about 30 seconds of trying. An actual sound type system built on top of regular JS would be unusable - you'd have to disallow almost everything. The language is too "dynamic" to become properly sound.

TheAceOfHearts 9y ago

I prefer Flowtype, but I definitely agree that TypeScript seems to be winning on the popularity front. One of the big problems is that flow has far fewer definition files available. Most projects don't want to support two separate type specs. Even if it didn't provide 100% compatibility, having something take you 90% of the way there would be a big improvement. But I'm still betting on flow. I like that it's supported by babel and it generally seems to be better at helping you catch bugs. @thejameskyle recently tweeted [0] a short snippet showing a great example showcasing flow. [0] https://twitter.com/thejameskyle/status/868148120504356864 https://twitter.com/thejameskyle/status/868148120504356864

AgentME 9y ago
Does Typescript still require you to have definitions for every library in order to use the library? One thing I love about Flow is that it doesn't have that requirement. You can start using a new library, and later on if you find that type safety in that library's exports would be useful, then you can look for or write definitions then. You're not blocked from adopting the library. I find for many of my dependencies that I use in a few spots it's not really important for me to have definitions for.
- typebore 9y ago
  technically you do need to define at the top level, but no, not in a practical sense: declare var $: any; $( "element" ).compiler.leaves.you.alone
- jsight 9y ago
  I don't think that Typescript ever did require that? AFAIK, it has always been possible to just declare the variable as "any" type and use it as if it were untyped.
  - neilsimp1 9y ago
    Can confirm. This has been my experience.
  - 9y ago

boubiyeah 9y ago

And for good reasons. flow started as "the better one of the two in theory" with better ideas, more strictness, way more expresiveness in its type system. But typescript took all these ideas, listened to the community and bridged the gap in features really fast, together with more stability, thus making flow pretty much obsolete. typescript is way more stable. I can take a nightly or RC version of typescript and I know it's going to work better than flow which I tried several times and always let me down. If you don't trust a type system, it's hard to justify using it at all, apart from the documentation it provides to other devs. These projects are complex, and I think only the typescript team invested enough to make it truly work.

bad_user 9y ago
> If you don't trust a type system, it's hard to justify using it at all, apart from the documentation it provides to other devs. 100% agree, although I have to wonder, why don't you see that Typescript is NOT a type system you can depend on. Fact of the matter is that Typescript has serious soundness issues and will always have. Those problems haven't disappeared. What this translates to in practice is that Typescript annotations are little more than documentation. And it simply doesn't compare with any sane static language where the first line of defense is the compiler.
- Silfen 9y ago
  > Typescript annotations are little more than documentation This is true at the boundaries of your codebase, but if your application is complex enough, tsc is a life saver. Typescript saves me from bugs literally every day. Not to mention the benefits around tooling and refactoring. Agreed that there are some big footguns with respect to soundness, though.
- resf 9y ago
  What is the practical benefit of soundness? I offer that soundness is a disease that makes programming languages far more complex than they have any right to be. A static type system exists to prevent some classes of bugs and enable code completion. However whenever "soundness" becomes a design goal, it enevitably usurps everything else (because it is an objective binary goal) and leads to languages that cease to value other things like simplicity or directness. A type system can never catch all bugs and reliable programs ultimately depend on a human being understanding and verifying the code. The most important goal - if you value reliable programs - is that the code is intelligible to people.

hamstercat 9y ago

It's pretty fun to use in React/React Native. Can't talk about Flow since I haven't tried it, but TypeScript definitely beats out plain JavaScript. What I like best is that it doesn't forces you to write your code differently than you would in JavaScript, it simply augments it with type information.

rattray 9y ago

stats to back that up: https://npm-stat.com/charts.html?package=flow-bin&package=typescript https://npm-stat.com/charts.html?package=flow-bin&package=ty... (the weekly view is easiest to parse) Looks like flow downloads have been declining week-on-week for the past 6 weeks. Note that flow is likely underrepresented, since many people install it with brew (or apt-get, or whatever).

akurilin 9y ago

Is flowtype actually getting left behind? What's the evidence for that? I'm simply curious because our team heavily invested in it over the past couple of years and I'd love to know ahead of time when it's time to jump ship.

habitue 9y ago
It's probably not time yet, but the winds are blowing that way so hard, I wouldn't be surprised if it becomes completely obvious in a couple years
whatever_dude 9y ago
It's not getting left behind, but it's as if two separate worlds exist. In the react/Facebook works, flow is the defacto default for many things.