Fast and precise type checking for JavaScript • Hacker News Board

Re: Fast and precise type checking for JavaScript

#11

Post by AnkhMorporkian » Thu, Nov 09, 2017, 5:04 AM UTC

oceanic wrote: post #8

dgreensp wrote: post #3

I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase. Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fa…

Apologies, offtopic: wait, Coda.io only uncloaked less than a month ago and you've already left??

I mean, I've worked for several companies and left months before they actually launched. Any contractor who works with startups have been through similar situations.

Can't speak for OP's situation though.

Re: Fast and precise type checking for JavaScript

#12

Post by besquared » Thu, Nov 09, 2017, 5:28 AM UTC

curryhoward wrote: post #10

hasenj wrote: post #6

Earlier quoted context omitted.

What is soundness, exactly, and how is Typescript unsound? It seems like a useless academic term that doesn't work so well in the real world, maybe?

Just as an example, this program type checks in TypeScript but crashes at runtime: class Dog { } class Greyhound extends Dog { doGreyhoundThing(): void { console.log("I am a greyhound!"); } } class Poodle extends Dog { doPoodleThing(): void { console.log("I am a poodle!"); } } function f(g:(Dog) => void) : void { let hound: Greyhound = new Greyhound(); g(hound); } function h(p: Poodle): void { p.doPoodleThing(); } f(…

They added contravariant functions in 2.6 using the compiler flag --strictFunctionTypes as described in this PR https://github.com/Microsoft/TypeScript/pull/18654

Re: Fast and precise type checking for JavaScript

#13

Post by _ar7 » Thu, Nov 09, 2017, 5:43 AM UTC

dgreensp wrote: post #3

I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase. Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fa…

Yeah I second this. Despite having a superior type system, flow is so behind in both tooling and 3rd party library definitions it's really hard to justify continuing to use it over typescript. It's weird to say, but the unsoundness of typescript doesn't matter much next to all the other advantages.

Besides, I feel like if I really want a strong type system https://reasonml.github.io/ might be the better choice over flow.

Re: Fast and precise type checking for JavaScript

#14

Post by chmln » Thu, Nov 09, 2017, 5:57 AM UTC

skydv wrote: post #7

chmln wrote: post #4

Flow capitalizes on its soundness, but its not as useful when the error messages are so cryptic. We tried adopting Flow at a company I worked at, but dealing with gibberish errors and the huge meaningless stack traces was a productivity sink. We migrated to Typescript. Error messages are more understandable and unlike flow include line numbers and the column. Add huge number of typings, and ts definitely wins. There…

so was it Angular or just a JS codebase?

It was a React codebase, which is why we were swayed towards Flow initially.

Re: Fast and precise type checking for JavaScript

#15

Post by maxbrunsfeld » Thu, Nov 09, 2017, 6:11 AM UTC

alangpierce wrote: post #9

hasenj wrote: post #6

Earlier quoted context omitted.

What is soundness, exactly, and how is Typescript unsound? It seems like a useless academic term that doesn't work so well in the real world, maybe?

Soundness means that if the type system says that a variable has a particular type, then it definitely has that type at runtime. A sound type system is always correct, and an unsound type system might be incorrect in some cases. Here's an example of unsoundness in TypeScript: https://www.typescriptlang.org/play/index.html#src=function%... TypeScript incorrectly (but conveniently) says that Array can be assigned to Ar…

Thanks for the really concise example.

Re: Fast and precise type checking for JavaScript

#16

Post by keratin » Thu, Nov 09, 2017, 6:23 AM UTC

swlkr wrote: post #2

I thought this was a new thing, but it turns out it's facebook's flow. https://flow.org

my thought as well, precisely..

Re: Fast and precise type checking for JavaScript

#17

Post by [deleted] » Thu, Nov 09, 2017, 6:36 AM UTC

hasenj wrote: post #6

chmln wrote: post #4

Flow capitalizes on its soundness, but its not as useful when the error messages are so cryptic. We tried adopting Flow at a company I worked at, but dealing with gibberish errors and the huge meaningless stack traces was a productivity sink. We migrated to Typescript. Error messages are more understandable and unlike flow include line numbers and the column. Add huge number of typings, and ts definitely wins. There…

What is soundness, exactly, and how is Typescript unsound? It seems like a useless academic term that doesn't work so well in the real world, maybe?

[deleted]

Re: Fast and precise type checking for JavaScript

#18

Post by hackits » Thu, Nov 09, 2017, 7:12 AM UTC

dgreensp wrote: post #3

I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase. Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fa…

Flow/Typescript both of great but writing from start from scratch both flow and typescript slow me down with all the hassle of needing to define the types of parameters and data structures. Typescript being a bit verbose at time too.

When working with another person API then typescript does become a godsend in helping understand what the bloody hell does this callback parameter are required.

Re: Fast and precise type checking for JavaScript

#19

Post by lewisl9029 » Thu, Nov 09, 2017, 9:01 AM UTC

I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly laid to rest with the introduction of the official ES modules spec (at least from the perspective of the application developer when it comes to module code they actually write), and I'm hoping an official type annotation spec can do the same for the JS static type checking landscape.

Flow has already long-since demonstrated that it's perfectly possible to introduce useful type annotations to JS code without changing any runtime behavior whatsoever, and Flow and TypeScript have mostly converged on similar syntax and semantics when it comes to the type annotations. Given all this, I'd have thought that the standardization process would be pretty far along by now. Maybe someone more familiar with these matters can offer some insight on the seeming lack of progress?

Re: Fast and precise type checking for JavaScript

#20

Post by yladiz » Thu, Nov 09, 2017, 9:04 AM UTC

alangpierce wrote: post #9

hasenj wrote: post #6

Earlier quoted context omitted.

What is soundness, exactly, and how is Typescript unsound? It seems like a useless academic term that doesn't work so well in the real world, maybe?

Soundness means that if the type system says that a variable has a particular type, then it definitely has that type at runtime. A sound type system is always correct, and an unsound type system might be incorrect in some cases. Here's an example of unsoundness in TypeScript: https://www.typescriptlang.org/play/index.html#src=function%... TypeScript incorrectly (but conveniently) says that Array can be assigned to Ar…

So Flow seem to be complaining that number and string are incompatible types for the array elements. I attempted to change your arr.push(3) statement to one that is appending a string, and it gave the same error even though it should not have given an error in that case.

Neither Flow nor TypeScript are correct in this instance. Neither keep track of the actual array element's value, just the general type of the array, which means they actually don't know for sure and do their best guess. So in the Flow example, it complains that the number and string types are incompatible even though it doesn't know that this specific case is incompatible, just the general case. In the TypeScript example, it should keep track of the type of the argument value supplied during the function invocation, not the type for the argument declaration.

In this case I would argue that even though TypeScript is incorrect, it's preferable to Flow because Flow doesn't infer that the types are incompatible from actual usage but theoretical.