Hacker News Reader

Comment by matsemann | Hacker News Reader

While I'm fan of statically typing, there is something with Typescript I don't like, but don't know exactly what it is. In my day-to-day it's mostly Kotlin and Elm, which also are both statically typed, which I don't mind and mostly don't even notice.

But with Typescript it is as if I'm always fighting the compilator, trying to make it happy with whatever code I wrote. Maybe it's just the JS ecosystem being too lax that makes having types for everything difficult? Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.

View on HN

I had this too - when I first started I fought typescript quite a bit. I struggled through this because I kept finding more and more code on github that was TS, kept seeing more articles that were TS, kept seeing big improvements from MS on TS, etc. So I kept learning the best practices and trying to understand why I shouldn't use "any[]" or "{key: string?}" and so on - trying to get past the parts where I wanted to be lazy. Eventually on one of my projects I had to reorganize my model structure, where some classes held other classes and so on. I had to both move one and rename one. This was early on, but since I did a reasonable job with typescript, I was able to just run `tsc -p .` over and over and it found all of the places I missed, which were far more than I would have guessed. It only took maybe 20 minutes to do that massive refactor. From that day forward, I really enjoy working in typescript. I think it's different from (some) other strongly/statically typed languages because it allows you be be a little more expressive in what you're defining. Perhaps expressive is the wrong word, but I find that it's quite flexible in this area, and I really enjoy that because if I take the time to flesh things out it can really help me find or prevent bugs.

Basically in the same boat, although I still use TS as it's become kind of defacto in JS land, I'm not sure that I dislike it so much as am not sure it's always worth it. Maybe I tend to approach it too much like Swift or Kotlin and get annoyed when a dependency is missing typings or the compiler is so easily tricked/lax about a lot of the actual type-saftey.

Maybe putting Typescript it into the bucket of a "better linter" is the mindset to have.

TS has a bit of Java feel to me. Forces me to follow all kinds of hard compiler requirements that take some time to implement, like generics, but then there's still all of these edge cases like null-pointers that make it feel like you're still building a house of cards.

Kotlin and Elm are more functional, don't know about Elm but Kotlin has non-null pointers as a base feature of it's language, not some later bolted on tie-wrapped solution.

> Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.

I’m curious - how do Elm and Kotlin solve these problems in a way that balances the often competing goals of “add types to reduce errors” vs “have a high productivity environment where it’s quick and easy for engineers to write new code”?

Elm and other ML-family languages have type inference, it does not ask a major part of human annoation of types while catches errors in compile time nonethelessly

Kotlin has type inference as well so typically you only write types in function signatures. It's rare that you write a type in a function body. Coupled with good IDE support for showing you the type of x in `var x = myFunc()` when you need it.

Reply on news.ycombinator.com