7 ms·
> But how much value does TypeScript add? All evidence points to the fact that TypeScript does not have any positive effect on bug density. Its value is purely
by frankpf 8y ago
> But how much value does TypeScript add? All evidence points to the fact that TypeScript does not have any positive effect on bug density. Its value is purely subjective and speculative.
This is objectively false. There is plenty of evidence showing that modern type systems reduce bugs considerably.
In Airbnb, they found out that 38% (!) of bugs could have been prevented by using TypeScript[1].
Another scientific study discovered that TypeScript and Flow could prevent about 15% of bugs in committed code [2]. And these aren't even measuring reduction of bugs in non-committed code!
Stripe is also writing their own type checker for Ruby and engineers have reported an increase in productivity[3].
[1]: https://news.ycombinator.com/item?id=19131272 https://news.ycombinator.com/item?id=19131272
[2]: https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...
[3]: https://sorbet.run/talks/StrangeLoop2018/#/ https://sorbet.run/talks/StrangeLoop2018/#/
- asark 8y agoTypescript also significantly reduces communication overhead and provides machine-verifiable documentation, making it way easier to figure out WTF is going on with unfamiliar or long-out-of-sight code. People who don't love TS compared with vanilla JS must work entirely differently from me—using it's the only time I've not hated writing JS. Tons of time-wasting poking about and background anxiety just gone. It's great, and costs almost nothing.
- phamilton 8y agoTypescript is a gamechanger with generated interfaces. We use it heavily with an RPC framework and pulling down the generated client and server packages have drastically minimized integration issues. It just takes away the mental overhead of making something conform to a spec. It probably doesn't save us much on production bugs, but it makes development faster.
- jondubois 8y agoGenerated interfaces are an anti-pattern. Types force tight coupling between clients and servers. What if a third-party project written in a different language wants to communicate with your server using their own client? Types will make it more difficult for them to integrate because: 1. If they're using a dynamically typed language, this gives them extra work to typecast everything back and forth whenever they need to communicate with your system. 2. Even if they use types, maybe their type system is not compatible with yours and they need to do a lot of tedious extra work to typecast everything.
- zwerdlds 8y agowhat is the solution? runtime errors?
- asark 8y agoHuh? Everything always has a type anyway. It's sometimes just harder to know what it is. Specifying doesn't make the types appear out of nowhere, it just documents them.
- true_religion 8y agoI wouldn't call that an antipattern. I treat other systems like I do the database and enforce consistency at the API level. I wouldn't ask for a database to be totally untyped (and thus silently coerce things into its internal types in reality), so I don't ask for the same in an API. Though, I can understand some people have differing preferences---MongoDB is popular for example---but I wouldn't call it an anti-pattern no matter which choice one makes.
- tom_ 8y agoNo, it makes it easier, because they have a specification to work from, and they can probably just use that spec to generate their own glue code, assuming any is necessary. I have never found option 2 to apply in any meaningful fashion, though I'm sure others have done much more of this type of work than I have.
- phamilton 8y ago
- jondubois 8y ago>> In Airbnb, they found out that 38% (!) of bugs could have been prevented by using TypeScript[1]. I don't buy these hypotheticals and also I don't believe in this kind of anecdotal evidence. I think that the real root problem is that they didn't break down the code into logical components and didn't test them correctly - That was the real problem, not JavaScript. When you look at reports of bug density across large samples of projects, it's clear that TypeScript does not solve any problems. See https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 https://medium.com/javascript-scene/the-shocking-secret-abou...
- frankpf 8y ago> I don't buy these hypotheticals and also I don't believe in this kind of anecdotal evidence. The only anecdotal evidence I've linked is Stripe's experience with Sorbet. The paper linked is an actual scientific analysis with great study design. I couldn't find the Airbnb slides or talk but an engineer involved claims the study was carefully designed[1]. > When you look at reports of bug density across large samples of projects, it's clear that TypeScript does not solve any problems. See https://medium.com/javascript-scene/the-shocking-secret-abou.. https://medium.com/javascript-scene/the-shocking-secret-abou.... Go read the "study" referenced in that article. It's just blog post with a terrible methodology. It's basically (number of issues with bug label) / (lines of code) The author doesn't even normalize for LOC (larger codebases tend to have more bugs) or take into account project complexity. [1]: https://twitter.com/swyx/status/1094857103863209985 https://twitter.com/swyx/status/1094857103863209985 EDIT: add disclaimer about airbnb talk
- keymone 8y agothe problem with study like airbnb is that while tooling would have caught X% of bugs of type A, it in no way means those wouldn't just be replaced by bugs of type B. bugs are (in part) function of code and tooling complexity, making some bugs harder to introduce doesn't reduce that complexity. risk compensation principle is another factor, and so on. i haven't yet seen strong evidence that static typing really reduces bug density.
- 8y ago