> The fact that there can be runtime type errors that were proven impossible at compile time is why I will never enjoy TypeScript.

The "impossibility" is just a trait of the type definitions and assertions that developers specify. You don't need to use TypeScript to understand that impossibilities written in by developers can and often are very possible.

▲

jstanley 3 hours ago | parent [-]

My first introduction to TypeScript was trying to use it to solve Advent of Code.

I wrote some code that iterated over lines in a file or something and passed them to a function that took an argument with a numeric type.

I thought this would be a great test to show the benefits of TypeScript over plain JavaScript: either it would fail to compile, or the strings would become numbers.

What actually happened was it compiled perfectly fine, but the "numeric" input to my function contained a string!

I found that to be a gross violation of trust and have never recovered from it.

EDIT: See https://news.ycombinator.com/item?id=46021640 for examples.

	▲	macguillicuddy 12 minutes ago \| parent [-]
		No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.