4 ms·

I don't really get why flow is okay when TS isn't? TS is gradually typed, you can work with unknown objects just fine and you don't have to dive fully in on you

I don't really get why flow is okay when TS isn't? TS is gradually typed, you can work with unknown objects just fine and you don't have to dive fully in on your code. Flow and Typescript actually have very similar approaches. So why is Flow better? Have you used Typescript and Flow recently and done a comparison? > But I always see a flock of comments saying that they couldn't possible live without static types, and thanking TS for taking them out of the hell of dynamism, and wishing there was something similar in Ruby/Python/whatever. > I don't really get that. Because we're really tired of writing the same errors over and over. If it's just me, I can burn through a bunch of clojure code and I'm fine. But the instant I and someone else start to collaborate, subtle problems start to creep in. What's more, so much of my job these days is about serialization, deserialization, data validation, and error handling. None of my customers have any patience for buggy software and sites. And quite frankly, they shouldn't be. Static typing just makes these tasks easier. It makes them easier because it reminds you when forget. It forces you to think about every edge case that it's aware of, and it forces you to say something you mean and if you change that opinion, you need to make sure the code reflects that change. You talk about static typing like Java and C++ are your experience. Using Typescript (or flow) or a modern FP like Typed Racket, Ocaml, F# or Haskell where the type systems enable new means of expressing yourself is wonderful and refreshing, to me.

qwertyuiop924 10y ago
Fair enough. The reason I like Flow better is that it's better integrated into the rest of the JS/Babel ecosystem, so it gets out of your way to a greater degree than TS when you're either not using it or want JS ecosystem integration with JSX/whatever.
- KirinDave 10y ago
  > JS/Babel ecosystem I mean, sure. In that when you use typescript you probably don't need/want Babel, as most of the ES6 features you want are part of TS already. > JS ecosystem integration with JSX/whatever. Typescript supports both react and non-react JSX natively, so perhaps this isn't a pain point anymore? Also: you get types. Good types are great.
  - qwertyuiop924 10y ago
    Well, yeah, but what about whatever thing comes along in Babel that will make your code an order of magnitude cleaner? What about all the tools that work with babel, rather than TS? And from what I saw, Flow has a type system at least as good as TS's. Am I wrong?
    - KirinDave 10y ago
      > Well, yeah, but what about whatever thing comes along in Babel that will make your code an order of magnitude cleaner? Why not watch http://channel9.msdn.com/Events/Build/2016/B881 http://channel9.msdn.com/Events/Build/2016/B881 and tell me what you think. It sounds to me like they're dedicated not only to being on that, but to be part of the conversation going forward. They're already taking the well-formed parts of the next 2 iterations of JS, and adding types on top. > And from what I saw, Flow has a type system at least as good as TS's. Am I wrong? Flow has a type system that is "as good" at troubleshooting errors within the existing javascript ecosystem, as I read it. And that's good. TypeScript, unlike flow, makes newer features available with the type data.
- spion 10y ago
  The problem is, Microsoft can't really do this. If they hired the creator of Babel, then proceeded to add TypeScript parsing support to it, they would immediately be accused of trying to "embrace, extend, extinguish". On second thought, that might not be such a bad idea. Babel already parses some type annotations, why not also add the little extra syntax supported by TypeScript?
  - qwertyuiop924 10y ago
    Babel has a plugin architecture. MS could implement the TS extensions as a Babel plugin, and it would integrate with any other Babel plugin. That's what facebook did.
    - spion 10y ago
      Yeah, it might be a good idea. A parser plugin to parse valid typescript, and a strip-types stage that strips them out.
      - qwertyuiop924 10y ago
        ...And that's what Flow does.
leshow 10y ago
Flow has better inference and is actually pursuing a sound type system. const f = function(a) { return a * 3; } f("stuff"); this will produce a runtime error with TS, Flow will fail to compile it. People here think that choosing a statically typed language necessarily means you need to type annotate everything, and thats not true. In Haskell and Elm you don't have to explicitly write any types if you don't want to. Elm doesn't produce javascript that contains runtime errors, and Flow is pursuing a similar goal.
- KirinDave 10y ago
  > const f = function(a) { return a * 3; } f("stuff"); Right but the instant you annotate a, it knows and gives you a good error. The reason TypeScript did this, to hear them tell it at Build, was because (unlike Flow, although they did not say it) they're a transpiler with a mission to actually make the tool usable with real world javascript. That's why, for example, type errors don't block code emitting but syntax errors do. It's in service of making a usable toolchain. Flow can be more aggressive because it's not making these decisions (its part of a larger configurable toolchain). Neither Flow nor Typescript can actually project soundness onto Javascript. Mentioning that is a giant red herring. So long as compatibility with base ecmascript is offered there is code which cannot be verified as sound or unsound without the execution context at hand. Typescript takes the approach that types are actually a useful tool for expressing concepts succinctly and safely and offers that first. Flow takes the approach that aggressive type inference is a phenomenal way to detect (potential) errors in javascript code, and takes that approach. Neither is wrong.
  - leshow 10y ago
    > Right but the instant you annotate a, it knows and gives you a good error unless you annotate it with :any > Neither Flow nor Typescript can actually project soundness onto Javascript. Mentioning that is a giant red herring. So long as compatibility with base ecmascript is offered there is code which cannot be verified as sound or unsound without the execution context at hand. I don't see how you can say that. Flow can absolutely create a 'sound' type system on top of javascript. Elm transpiles to javascript and has a sound type system that doesn't produce runtime errors. Flow has different syntax but it restricts the type system in a similar way.

qwertyuiop924 10y ago

Fair enough. The reason I like Flow better is that it's better integrated into the rest of the JS/Babel ecosystem, so it gets out of your way to a greater degree than TS when you're either not using it or want JS ecosystem integration with JSX/whatever.

KirinDave 10y ago
> JS/Babel ecosystem I mean, sure. In that when you use typescript you probably don't need/want Babel, as most of the ES6 features you want are part of TS already. > JS ecosystem integration with JSX/whatever. Typescript supports both react and non-react JSX natively, so perhaps this isn't a pain point anymore? Also: you get types. Good types are great.
- qwertyuiop924 10y ago
  Well, yeah, but what about whatever thing comes along in Babel that will make your code an order of magnitude cleaner? What about all the tools that work with babel, rather than TS? And from what I saw, Flow has a type system at least as good as TS's. Am I wrong?
  - KirinDave 10y ago
    > Well, yeah, but what about whatever thing comes along in Babel that will make your code an order of magnitude cleaner? Why not watch http://channel9.msdn.com/Events/Build/2016/B881 http://channel9.msdn.com/Events/Build/2016/B881 and tell me what you think. It sounds to me like they're dedicated not only to being on that, but to be part of the conversation going forward. They're already taking the well-formed parts of the next 2 iterations of JS, and adding types on top. > And from what I saw, Flow has a type system at least as good as TS's. Am I wrong? Flow has a type system that is "as good" at troubleshooting errors within the existing javascript ecosystem, as I read it. And that's good. TypeScript, unlike flow, makes newer features available with the type data.
spion 10y ago
The problem is, Microsoft can't really do this. If they hired the creator of Babel, then proceeded to add TypeScript parsing support to it, they would immediately be accused of trying to "embrace, extend, extinguish". On second thought, that might not be such a bad idea. Babel already parses some type annotations, why not also add the little extra syntax supported by TypeScript?
- qwertyuiop924 10y ago
  Babel has a plugin architecture. MS could implement the TS extensions as a Babel plugin, and it would integrate with any other Babel plugin. That's what facebook did.
  - spion 10y ago
    Yeah, it might be a good idea. A parser plugin to parse valid typescript, and a strip-types stage that strips them out.
    - qwertyuiop924 10y ago
      ...And that's what Flow does.

leshow 10y ago

Flow has better inference and is actually pursuing a sound type system. const f = function(a) { return a * 3; } f("stuff"); this will produce a runtime error with TS, Flow will fail to compile it. People here think that choosing a statically typed language necessarily means you need to type annotate everything, and thats not true. In Haskell and Elm you don't have to explicitly write any types if you don't want to. Elm doesn't produce javascript that contains runtime errors, and Flow is pursuing a similar goal.

KirinDave 10y ago
> const f = function(a) { return a * 3; } f("stuff"); Right but the instant you annotate a, it knows and gives you a good error. The reason TypeScript did this, to hear them tell it at Build, was because (unlike Flow, although they did not say it) they're a transpiler with a mission to actually make the tool usable with real world javascript. That's why, for example, type errors don't block code emitting but syntax errors do. It's in service of making a usable toolchain. Flow can be more aggressive because it's not making these decisions (its part of a larger configurable toolchain). Neither Flow nor Typescript can actually project soundness onto Javascript. Mentioning that is a giant red herring. So long as compatibility with base ecmascript is offered there is code which cannot be verified as sound or unsound without the execution context at hand. Typescript takes the approach that types are actually a useful tool for expressing concepts succinctly and safely and offers that first. Flow takes the approach that aggressive type inference is a phenomenal way to detect (potential) errors in javascript code, and takes that approach. Neither is wrong.
- leshow 10y ago
  > Right but the instant you annotate a, it knows and gives you a good error unless you annotate it with :any > Neither Flow nor Typescript can actually project soundness onto Javascript. Mentioning that is a giant red herring. So long as compatibility with base ecmascript is offered there is code which cannot be verified as sound or unsound without the execution context at hand. I don't see how you can say that. Flow can absolutely create a 'sound' type system on top of javascript. Elm transpiles to javascript and has a sound type system that doesn't produce runtime errors. Flow has different syntax but it restricts the type system in a similar way.