Fast and precise type checking for JavaScript
blog.acolyer.org
Fast and precise type checking for JavaScript
1–10 of 41 posts
Re: Fast and precise type checking for JavaScript
#2I thought this was a new thing, but it turns out it's facebook's flow. https://flow.org
Re: Fast and precise type checking for JavaScript
#3I 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 fast-moving, with bugs fixed and features added at a high rate, and the quality of discussion on the issue tracker is high. Flow, in comparison, was not evolving as fast.
Flow touts global inference, which I think means better types when you don't necessarily have annotations on module boundaries, but I mostly care about what's possible in a greenfield or well-annotated codebase.
Flow deserves a ton of credit, and Microsoft probably studied it in detail, but I think the advantages are overblown at this point. Take the soundness thing. TypeScript added null-strictness a while ago, and recently they improved function type polymorphism. The reality is that both type systems have limits and you sometimes need to type something imperfectly or use an escape valve ("any"). In most cases, however, TypeScript gives you more sophisticated tools to construct the types you want, so you actually get better types. Maybe TypeScript lacks a theoretical underpinning for soundness, but there's no reason it can't continue to get "more and more sound," with it harder and harder to find good examples of unsoundness.
Re: Fast and precise type checking for JavaScript
#4Flow 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 are many gripes we've had with typescript too, but at least we didn't spend hours trying to understand error messages.
Re: Fast and precise type checking for JavaScript
#5I thought this was a new thing, but it turns out it's facebook's flow. https://flow.org
Yes, it would be good to add that to the title
Re: Fast and precise type checking for JavaScript
#6Flow 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?
Re: Fast and precise type checking for JavaScript
#7Flow 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?
Re: Fast and precise type checking for JavaScript
#8I 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??
Re: Fast and precise type checking for JavaScript
#9Flow 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?
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 Array, and you can exploit that to create an "s" variable that TypeScript thinks is a string but is actually a number.
You can try the same code in Flow and it gives a type error:
https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEA...
Re: Fast and precise type checking for JavaScript
#10Flow 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?
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(h);