Hyper-Typing
11 comments
·May 5, 2025omneity
jy14898
> An API call, reading a file, calling less well-behaved libraries or making some system calls can all result in objects that pass compile-time checks but will cause a runtime exception or unexpected behavior.
Seems crazy to me to have this attitude, the whole point of typescript (and indeed many other languages with type checkers) is that we can leave out unecessary checks if proven by the compiler. The burden of compatibility is on the caller to ensure they supply correct values
omneity
I don't systematically pick one or the other location for these guards, but wouldn't it make more sense to have it in one place, the function itself, both for DRY and to ensure it being checked, rather than on every call site?
Such a requirement "oh yeah always guard your arguments for calls against this function for the "same" thing your compiler is doing anyway" shouldn't be implicit and duplicated everywhere if it's always meant to be fulfilled.
jy14898
I think I take the attitude that you parse/validate data as soon as possible (ie when reading a file/coming from an API), so that the rest of the code can rely on typechecks alone.
That said, I come from a background where the language doesn't let you consider that the type of a value might be wrong (Haskell, for example), so perhaps I have more trust than typescript deserves.
Klaster_1
> An API call, reading a file, calling less well-behaved libraries or making some system calls can all result in objects that pass compile-time checks but will cause a runtime exception or unexpected behavior.
These all boil down to implicit `as` type casting parsed boundary data into expected types. What you suggest is replacing casts with to type narrowing guards, libraries like Zod help with some of that. I think TS needs a special flag where `JSON.parse` and alike default to `unknown` and force you to type guard in runtime.
pjc50
> An API call, reading a file, calling less well-behaved libraries or making some system calls can all result in objects that pass compile-time checks but will cause a runtime exception or unexpected behavior.
Yeah, that is a design flaw that makes this kind of solution less useful than it might be. C# has this problem with "nullable": just because you've marked a type as not nullable doesn't mean some part of the program can't sneak a null in there. Haskell people wouldn't stand for that kind of nonsense.
jfjfjtur
I think the point though was that practical solutions can be imperfect, and spending complexity in an attempt at perfection can lead to impractical solutions.
pscanf
Author here. Curious to hear if anyone's experience also matches mine, or if instead you find the trade-off to be worth it most of the times. :)
shirol
I don't use typing for correctness. I use it for documentation. That's why I prefer JSDoc these days. I only type top-level variables/functions to get hints from my editor. Everything inside a function body remains untyped unless necessary. It’s the benefit of using Typescript without being forced to write dumb code just to satisfy the compiler.
matijs
Absolutely matches your experience!
Also curious about the delightful type generation Astro uses.
agos
my experience absolutely matches yours. Navigating the types of many libraries is often daunting (MUI, React-Aria, react-hook-form to name a few)
> The strictness even allows us to remove the if check inside the function, since now TypeScript gives us the compile-time guarantee that obj will always have property key.
This is a dangerous suggestion. While the author does acknowledge it is a compile-time guarantee only, that doesn’t imply it is safe to remove the if inside the function.
An API call, reading a file, calling less well-behaved libraries or making some system calls can all result in objects that pass compile-time checks but will cause a runtime exception or unexpected behavior.
As for the thesis of TFA itself, it sounds quite reasonable. In fact a high “level” of typing can give a false sense of security as that doesn’t necessarily translate automatically to more stable applications.