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.
JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.
Disagree that full type safety would require a lot of runtime checks. That's not the experience I've had in ReasonML.
Why would this be the case?
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)
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.
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.
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).
TypeScript has a dog of a compiler, I'll give you that. But that wasn't what I was referring to.
- https://reasonml.github.io/docs/en/editor-plugins
- https://reasonml.github.io/docs/en/faq#why-are-bucklescript-...
- Oh, and a really fun one from TypeScript: https://news.ycombinator.com/item?id=20045066