Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

> What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small).

When I was playing with TS I converted a project and found no additional bugs. Type related bugs shouldn't be that common IMO (if they are and they're systemic (not like a one off) I would argue that there is an issue with the way you're architecting).

Maybe TypeScript just isn't for me. I see its value but didn't find it high enough to continue using. I'm working on creating a .d.ts file for one of my open source libraries but I don't know that I'll use it beyond that anytime soon.

View on HN

To me, the value is at design/write time, not in converting old code. Old code that already works correctly will not be made more correct with TS unless you have branches of code that haven't been tested (by you during development, in tests or by your users). Working TS just lets me catch type mismatches while I'm writing instead of after the whole build process has run and I've reloaded the browser.

Also don't forget refactoring. Try renaming a property with confidence in plain JS. In TS it is simple.

No problem if you test your code, as you should.

Somehow, a failing test isn't quite as convenient as a reliable renaming operation.

Granted, but a renaming option is just that. A test will not only provide confidence, but also tell you if the code contains a logical bug.

No, a test will tell you whether or not that test passes; it says nothing about the correctness of anything else. But at this point, you're doing the job of a typesystem.

> No, a test will tell you whether or not that test passes; it says nothing about the correctness of anything else.

That is a tautology: Of course a failing test shows you that the test failed. However, your test suite is severely flawed if the type system makes it redundant.

There's a whole class of type mismatch bugs, which can show up in one or more code paths of just about any practical program, and which can be eliminated by a type checker (instantly in your text editor if you set it up, or at compile time). If you are writing and maintaining tests for lots of these bugs, you should consider adding a type checker to do it for you. The difference in overhead between annotating a variable and writing a test is huge.

Which, again, proves my point: If your test suite can be reduced to a type checker you are doing it wrong. That being said, it does not mean that a type checker won't catch many of the same bugs tests do - but no more than a subset.

Yes, good tests is the only way to eliminate most bugs. But aside from overhead to add tools to a project (don't underestimate the potential difficulty of this), a type checker can cover its subset for free, and then you can get better test coverage overall.

Yeah, I think the bug-finding value is overblown. I advocate Typescript entirely for developer experience. It lets me codify complex domain objects and will catch the obviously wrong bugs while I'm developing -- things like passing arguments in the wrong order or passing an x to a function instead of a y. Not to mention with Webstorm or VSCode you have actually reliable autocomplete too.

Reply on news.ycombinator.com