4 ms·

This is a great distinction! With typescript getting wider use, I've found myself frustrated by the limitations of bolt on type systems. Knowing how deep the di

This is a great distinction! With typescript getting wider use, I've found myself frustrated by the limitations of bolt on type systems. Knowing how deep the divide is from languages with fully inferrable types gives me more appreciation for how much work went into the current state of inferencing tools.

shepherdjerred 3y ago
I found TypeScript to be _incredible_ once you use a runtime validation library like Zod or io-ts. TypeScript itself has a great type system, but the culture in TS is to use `any` at the boundaries of your app, e.g. in parsing HTTP requests, local storage, URL routes -- any data outside of the type system. This greatly reduces how much a type system can help you. Zod, io-ts, and other similar library, allow you to enforce type constraints at runtime in a very sleek, easy way, and they don't require you to write your types twice, either. I've found that this makes TypeScript feel almost as safe as languages with much better type systems, e.g. Haskell.
- DylanSp 3y ago
  The Typescript team has been pushing the use of `unknown` instead of `any` for typing data at the boundaries of your app; how much of that has shown up in the ecosystem? EDIT: I definitely agree with your general point, for the record.
  - shepherdjerred 3y ago
    unknown definitely helps, but it doesn't solve the problem. You still need to get the data from unknown -> your type. Most people will resort to casting, which is unsafe. Runtime type libraries let you know _for sure_ that the type is correct. example: https://tinyurl.com/yc74stm6 https://tinyurl.com/yc74stm6 I adopted this pattern at work for all of our API calls, local storage, route parameters, etc.. The result was the app was fully typed, and we handled every case of invalid data in a reasonable way. When data is invalid, we can provide a sane default value.
    - DylanSp 3y ago
      Definitely agreed that it's not a perfect solution, just that it's better than blindly using `any`. Using type assertions to get around it defeats the point, though, and it is frustrating when people do that.

shepherdjerred 3y ago

I found TypeScript to be _incredible_ once you use a runtime validation library like Zod or io-ts. TypeScript itself has a great type system, but the culture in TS is to use `any` at the boundaries of your app, e.g. in parsing HTTP requests, local storage, URL routes -- any data outside of the type system. This greatly reduces how much a type system can help you. Zod, io-ts, and other similar library, allow you to enforce type constraints at runtime in a very sleek, easy way, and they don't require you to write your types twice, either. I've found that this makes TypeScript feel almost as safe as languages with much better type systems, e.g. Haskell.

DylanSp 3y ago
The Typescript team has been pushing the use of `unknown` instead of `any` for typing data at the boundaries of your app; how much of that has shown up in the ecosystem? EDIT: I definitely agree with your general point, for the record.
- shepherdjerred 3y ago
  unknown definitely helps, but it doesn't solve the problem. You still need to get the data from unknown -> your type. Most people will resort to casting, which is unsafe. Runtime type libraries let you know _for sure_ that the type is correct. example: https://tinyurl.com/yc74stm6 https://tinyurl.com/yc74stm6 I adopted this pattern at work for all of our API calls, local storage, route parameters, etc.. The result was the app was fully typed, and we handled every case of invalid data in a reasonable way. When data is invalid, we can provide a sane default value.
  - DylanSp 3y ago
    Definitely agreed that it's not a perfect solution, just that it's better than blindly using `any`. Using type assertions to get around it defeats the point, though, and it is frustrating when people do that.