> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer.
No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types.
> This way you can have type safety without losing JS features.
IMHO, you can't get type safety out of an unsound type system. (Which TypeScript is, by choice.) I think surprises like the above drive that point home.
TypeScript’s goal isn’t to be sound. Its goal is to be a balance between type-safety and effort. Full type safety would require a lot of runtime checks injected into the final JavaScript, which TypeScript intentionally avoids.
JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.
Many type-safe languages throw an exception if you attempt to access an element in an array that is out of bounds but javascript just returns undefined.
Typescript ignores the fact that accessing an arbitrary element of an array could return undefined. If it did not ignore this fact then it would force you to deal with the potential undefined value retrieved from any array access (i.e you'd need to write a runtime check)
Index unsafety w.r.t. bounds and `undefined` is something TS would like to fix; but it's not ergonomic to fix until there are, something like automatic refinement range types applied to array length fields. Without it, TS'd get in the way, demanding `undefined` checks it almost definitely didn't need. Those range types and their complexity are, ultimately, what currently block TS from making these indexed accesses safer.
Some languages do force you to check any time you access an element. If the rest of the language is in line with this, then it's actually amazing. Option/Maybe types help here, pattern matching lists also let's you make sure you handle all cases.
In some instances it makes sense to use a special NonEmptyList type that guarantees there is always at least one element, so you don't need to check.
There's a thing called dynamic type checking. It's literally all type checking done at runtime.
Even for mostly static typed languages you may want to lookup what a downcast is, it's not obscure.
I'm not talking about type checking with your run time code. Obviously this is exists. My mistake with the wording.
I am referring to the topic the poster is talking about, that is, type checking with type script and the precompile type checker of almost all statically typed languages.
The precompile type checks do not need run time code. These are separate things executed at separate times AND really you can get by with 100% static.
The thing is... it doesn't seem to matter. After 30-40k lines of TS code (coming from OCaml) I am still to find a bug where OCaml would have done a better job, except for missing features like nominally typed primitives and no pattern matching. And these are hopefully coming to TS/JS
> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer.
It helps sticking mostly to interfaces as it helps managing expectations. Class information gets discarded during compilation and that brings with it some quirks. Java Generics is another example where type erasure leads to quirky surprises.
Yes, I realize that's not the goal which is why I said 'by choice'. I just think it's not the right approach ultimately. Other safer languages also reach the goals of code completion and error detection.
Most of the highly typed languages actually do a poor job with code completion and error handling, they were specifically designed with safety in mind and other aspects of the type system are given only secondary attention. TyoeScript is nice because it focuses on where type systems are really useful (feedback) as a first concern.
Fortunately, the typed AltJS language with the highest interest levels after TypeScript actually has really good code completion and error reporting :-)
Oh, and build speeds so fast that it's blink-and-you-miss-it. I think that's a pretty important part of useful feedback (and one that I hear TypeScript is not that great at).
No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types.
> This way you can have type safety without losing JS features.
IMHO, you can't get type safety out of an unsound type system. (Which TypeScript is, by choice.) I think surprises like the above drive that point home.