3 ms·

That’s great, but sometimes those tools fail to spot an error silently, where a compiler plus runtime checks usually won’t.

by ok_dad 4y ago

miohtama 4y ago
As an extensive user and a fan of these Python type checking tools, I do not remember this happening for some years now. Do you have a particular example where it should be improved?
- ok_dad 4y ago
  Yea, at work mypy fails quite often on the old code there.
- v0idzer0 4y ago
  Never once happened to me in years of typescript, though I agree it’s obviously possible
  - still_grokking 4y ago
    Such a major failure was my first (and last) experience with TS about two years ago. Had all the "strict" options set, was quite happy finally using a "type safe JS", and boom, it exploded at runtime with some nasty bug which was discovered not before having the code run in production. Than I learned that TS' "type system" isn't sound, and you're required to write tests even for the parts that should be actually covered by the "types". That's not helpful at all. That's not what I expect from type safety.
    - Throwaway234590 4y ago
      Was this blow up due to a dependency with an 'any' type somewhere, and your code fed the dependency library some garbage? That's what bit me, even with the strictest ts settings, this can't be picked up by tsc.
      - still_grokking 4y ago
        I don't know anymore what it was concretely. That was two years ago on some project that wasn't even part of my usual duties. We lost some team members and I had to look after some extra projects. As I have quite some experience with JS I was given a TS task. At this point I was even quite eager to update my JS skills with TS knowledge. All in all it was fun to write this project. But my error was to trust the types like I would when programming on my main project in Scala. Big error… Since than I think TS is much oversold. You can do fun things with the types (even some things that I miss in Scala, and there is not much to miss in Scala in general!), but you just can't trust the TS types. So this makes them superfluous in some sense. (Yes, some types are better than no types; especially when it comes to the IDE experience; but as long as any lib call (due to trivial bugs in "typing-files"), or some "impossible" input can break things this is not as helpful as one would like; especially when coming form really strongly typed languages).
- Too 4y ago
  Same. As long as you sanitize dynamic serialized input like json while parsing this is not a problem. Later versions are very strict even about dynamic types, treating them as Union[] rather than Any, forcing you to check the type before using it. Likewise with strict non nullable.

That’s great, but sometimes those tools fail to spot an error silently, where a compiler plus runtime checks usually won’t.

by ok_dad 4y ago

That’s great, but sometimes those tools fail to spot an error silently, where a compiler plus runtime checks usually won’t.

miohtama 4y ago

As an extensive user and a fan of these Python type checking tools, I do not remember this happening for some years now. Do you have a particular example where it should be improved?

ok_dad 4y ago
Yea, at work mypy fails quite often on the old code there.
v0idzer0 4y ago
Never once happened to me in years of typescript, though I agree it’s obviously possible
- still_grokking 4y ago
  Such a major failure was my first (and last) experience with TS about two years ago. Had all the "strict" options set, was quite happy finally using a "type safe JS", and boom, it exploded at runtime with some nasty bug which was discovered not before having the code run in production. Than I learned that TS' "type system" isn't sound, and you're required to write tests even for the parts that should be actually covered by the "types". That's not helpful at all. That's not what I expect from type safety.
  - Throwaway234590 4y ago
    Was this blow up due to a dependency with an 'any' type somewhere, and your code fed the dependency library some garbage? That's what bit me, even with the strictest ts settings, this can't be picked up by tsc.
    - still_grokking 4y ago
      I don't know anymore what it was concretely. That was two years ago on some project that wasn't even part of my usual duties. We lost some team members and I had to look after some extra projects. As I have quite some experience with JS I was given a TS task. At this point I was even quite eager to update my JS skills with TS knowledge. All in all it was fun to write this project. But my error was to trust the types like I would when programming on my main project in Scala. Big error… Since than I think TS is much oversold. You can do fun things with the types (even some things that I miss in Scala, and there is not much to miss in Scala in general!), but you just can't trust the TS types. So this makes them superfluous in some sense. (Yes, some types are better than no types; especially when it comes to the IDE experience; but as long as any lib call (due to trivial bugs in "typing-files"), or some "impossible" input can break things this is not as helpful as one would like; especially when coming form really strongly typed languages).
Too 4y ago
Same. As long as you sanitize dynamic serialized input like json while parsing this is not a problem. Later versions are very strict even about dynamic types, treating them as Union[] rather than Any, forcing you to check the type before using it. Likewise with strict non nullable.