Comment by Androider | Hacker News Reader

Comment by Androider | Hacker News Reader

Parent Full thread

The type of problem that TypeScript solves is not the type of problem that I have.

In my 15 years of engineering, exceedingly rare is the case where the underlying cause is due to using wrong types. I could count the number of times types has been problem on one hand. Instead, almost all issues are due to logic errors and missing or poorly understood business requirements.

For me, the time spent resolving TypeScript specific issues (missing type definitions, lack of support in third party libraries, general finickiness etc.) does not make it a worthwhile investment. I also did Scala for several years professionally, and while it instils rigor, I feel much the same that the price you pay isn't remotely worth the benefit you get. Conversely, I think one of the best investments you can possible make into tooling is to reduce the edit-compile-view cycle time, and you should aim for seconds at the most if not instantaneous updates. That speed of iteration will pay dividends.

> In my 15 years of engineering, exceedingly rare is the case where the underlying cause is due to using wrong types

The thing I've come to realize when using languages with more robust type systems is this:

All errors in code are type errors, but not all type systems are expressive enough to fully express the invariants that logically apply to a piece of code.

That said, in nearly 40 years of programming, I've frequently encountered type errors in both my and other people's code that a type system like TypeScript’s is sufficient to statically avoid.

It's a charmed life where one hasn't had to spend countless hours helping other people track down "undefined is not a function" errors :|

I did that a lot at my last job and found that the debugging was pretty quick. There’s always some race condition from some asynchronous function somebody called without waiting for the callback. Does TS help with that?

if something can be returned as undefined instead of a function, then yes, you are forced to either write code to handle the undefined value, or modify your logic so the returned value can only be a function :)

I thought the same but the more I use TypeScript the less I care about it's typechecker. I use it mostly for the amazingly powerful IDE integration and so I don't have to remember if a `User` has an `id` or a `userId`.

I've noticed VSCode at least also learns types and structures from JSDoc in raw / vanilla JavaScript.

Not only VSCode, it's a documented feature of the ts compiler. https://www.typescriptlang.org/docs/handbook/type-checking-j...

iirc Webpack uses it extensively in its codebase

Isn't this solved if you treat user defined (re: the developer) Types as an expression of business logic? Not so much as a way to signal inputs & outputs, but a way to expression why, how, and when those inputs & outputs are augmented?

Just having the ability to tag a functions param type as `string` is otherwise useless, other than trivial callsite validation, for instance.

> In my 15 years of engineering, exceedingly rare is the case where the underlying cause is due to using wrong types.

That just means you've never used a powerful enough type system. With a powerful type system, it's incredibly easy to make type errors. You'll find that you spend a ton of time fixing all of these type errors that suddenly appeared in your code.

You don't refactor your code? Fix bugs months after development? I suppose you aren't the target audience..

There are a lot of projects that are just deliver-and-forget.

Reply on news.ycombinator.com