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.
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`.
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.
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.