4 ms·
TypeScript only provides the illusion of type safety. At runtime, it’s just plain old JS where all bets are off. I’ve been bitten too many times. As long as
by GiorgioG 6y ago
TypeScript only provides the illusion of type safety. At runtime, it’s just plain old JS where all bets are off. I’ve been bitten too many times. As long as there’s no native TS runtime were stuck pretending we have type safety.
- eropple 6y agoIn my experience nobody is "pretending"; within epsilon of everyone knows this, and the experienced folks are writing code against it with something like `runtypes` or `io-ts` to sanitize on the edges of their application.
- valand 6y agoHappened to me This helps me with it at the cost of a little bit more lines of code https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts
- saghm 6y agoI'm not sure I understand this comment. I can believe that typescript might not be typesafe, but what does the runtime not having type information have to do with that? If a compiler only accepts sound programs, then it shouldn't matter whether the runtime actually knows about the types or not (unless you want to do some sort of reflection, but allowing that is arguably _less_ typesafe). By that logic, you'd also have to consider anything that compiles to native code also not to be typesafe, because there sure aren't types in assembly.
- Townley 6y agoFor me, the main place the issue above rears it’s head is in data retrieved from an API. A strongly-typed language would fail loudly and predictably if a blob of JSON didn’t match the expected format. In some situations, that’s preferable to having invalid data work it’s way through the system, or having to manually implement type checking I’m a fan of the Runtypes library for this use case. If you design your typescript interfaces using the library (admittedly a bit magical to me) you can get runtime errors if API data doesn’t match the expected type
- neurotrace 6y agoYou can use guard functions to validate external data. This same problem comes up in other statically typed languages. You can't guarantee that external data will be in the shape that you expect so you must validate it. If you're just taking your `unknown` API response and immediately casting it to your desired type then that's your fault, not TS
- eropple 6y agoThat's what runtypes is.
- fy20 6y agoYou can use something like io-ts or zod to validate external data at runtime.
- Vinnl 6y agoYeah, ideally JSON.parse() returned `unknown`, but unfortunately that was added after the current type definition was already in widespread use, and therefore would be too much of a breaking change. Perhaps some day with a compiler flag.
- TheCoelacanth 6y agoIsn't that basically what the noImplicitAny flag does?
- Vinnl 6y agoUnfortunately no: that only errors when you do not add a type annotation and TypeScript can't infer anything better than `any`. JSON.parse(), however, is explicitly annotated to return any. See [1]. [1] https://www.typescriptlang.org/play?#code/PTAEEkDsDMFMCd6wCagC4HtQCNagIaQCeo08GAtqAFIDKA8gHIB0ADvvAM6wDknosAB6sANgEsAxmLSgkaAK7xI6Iq1gAuAFASMkTjMIBRQfgqjYANQ5j82EXgC8NBi3ZdYACgBEACVgiRLAB1DHgRZC8ASgBubV1ODHtmQIBzDyMTM3sreBs7WBjNTRAIGAQkVEwcPEISXAl8eW50AAsEPDF+SAw0FrFIFPQsfrh4Vrw0VTwySi1oeUgJNDFddFh9DzEsyWkRIgBBYkjQAG9NUAvQHT1E2GSMNK3RHbQ9w6JCgF9NIA https://www.typescriptlang.org/play?#code/PTAEEkDsDMFMCd6wCa...
- schwede 6y agoThey are probably talking about accepting serialized data coming from a network request. Typescript doesn’t help at the edge if you just cast your JSON blob into your application model.
- andyfleming 6y agoThat's why you actually have to validate at the edge. TypeScript doesn't really change that fact. It only makes the decision of how you handle it explicit.
- deleted 6y ago[deleted]
- b34r 6y agoThat’s what Deno is for
- tomphoolery 6y agoI feel like this is the same argument that people give when trying to justify not writing tests. Tools like type-checking and automated tests aren't a magic forcefield that will shield you from any and all runtime bugs. But they do protect against a good percentage of them, and as another commenter pointed out...70% type-checking is better than 0% type-checking. The point of type-safety is to be able to describe more succinctly what the _programmer_ expects out of the code. As you said, when you get to production, "all bets are off". This still applies with any type-safe language. Types don't exist when you're compiling to machine code, either.
- lmm 6y ago> 70% type-checking is better than 0% type-checking. I'm not sure it is; the most dangerous things in programming are assumptions that are almost correct, so you don't notice the problem until it's too late. An error whose symptom is an Int actually being a String several files away from where the mistake actually happened can be harder to diagnose than the same error in a untyped language, just because it's so contrary to your expectation.
- gitgud 6y agoTrue, but it's the benefit of incremental adaptation of types on an old code based. It also encourages better architecture in my opinion, as it forces you to reduce the importance of something being an exact type... As it's not strictly enforced at runtime.
- deleted 6y ago[deleted]
- yashap 6y agoHuh? The whole point of static typing, in any language, is basically: - Catch more errors at compile time - Better tooling (better intellisense, “go to definition”, “find implementations”, etc.) TypeScript provides both of these benefits just fine. Runtime types give you better runtime errors, and less undefined behaviour, but plain JS (or TS compiled to JS) does that bit just fine. TS types persisting at runtime could maybe be nice for certain use cases, like more powerful reflection, but that’s not type safety. What’s a concrete example where your program would be more safe if TypeScript types were represented at runtime?
- saiojd 6y agoI agree somewhat, the errors it misses are precisely the ones which are confusing.