5 ms·

Types can be asserted at runtime (parsed) at IO boundaries (reading http request or response, websocket message, parsing json file etc). Once they enter statica

Types can be asserted at runtime (parsed) at IO boundaries (reading http request or response, websocket message, parsing json file etc). Once they enter statically type system they don't need to be asserted again. The difference it makes is illusion of type-safety vs type-safety this article touches on. It's basically mapping of an `unknown` type into known one, at runtime. You can try to bind service with client (types) somehow but in many cases this will fail in production as you can't guarantee paired versioning, due to normal situations by design of your architecture or temporary mid-deployment state or other team doing something they were not suppose to do (new client is deployed connecting to old service or vice versa) etc. It's hard to avoid runtime parsing/type assertion in general. Functional combinator approaches like [0] or faster [1] with predicate/assert semantics work very well with typescript, which is very pleasant language to work with. [0] https://github.com/appliedblockchain/assert-combinators https://github.com/appliedblockchain/assert-combinators [1] https://github.com/preludejs/refute https://github.com/preludejs/refute

the_duke 5y ago
That's only partially true for Typescript and requires a lot of discipline. TS is continuously getting better, but it's still possible to lose type safety with some constructs without the compiler warning you about it at all. The third party typings for JS dependencies are also often not a 100% correct, especially for rare code paths and edge cases. And due to how easy it is to fall back to any, there are also Typescript native libraries that don't uphold the guarantees they seem to give. Typescript is great, but it's far from bullet proof, and it's extremely frustrating to deal with bugs that the type system supposedly should have prevented.
- frenchyatwork 5y ago
  Some of those issues can be remedied by linting rules (preventing unsafe use of any), but typing of dependencies can be a headache. Even 1st party typing and Typescript dependencies can regularly be wrong if type safety was not important to whoever wrote them.
  - mirekrusin 5y ago
    Absolutely, some of linter rules are very useful, ie. type-aware ones.
- mirekrusin 5y ago
  We're lucky where no- or very shallow- dependencies for our backend services are possible. I hear from collegues it's different world on f/e. It's true there are tons of poor quality libraries - both in pure js and ts. We try to avoid this transitive dependency explosion nonsense alltogether. Even well known libraries like lodash, which are not typescript first – are simply too dynamic. If ts doesn't offer precise types on functions – we avoid those. From our experience it looks like it pays off well to put an extra effort to guarantee that static types are correct and precise – no dependencies or trimmed to absolute minimum, rely on ts first code (usually ours), no dynamic fiddling that can't be expressed in ts, no any, no pretending via casting/non-null assertions, parsing/runtime-assertions on io-boundaries etc. Together with other techniques like branded types typescript can enter critial systems in enterprices – areas where js would never be allowed to exist. As you say it requires discipline – but I wouldn't call it "a lot", not in our case at least, the effort/benefit ratio is no-brainer in our case and at the end – it's honestly very pleasant language to work with.

the_duke 5y ago

That's only partially true for Typescript and requires a lot of discipline. TS is continuously getting better, but it's still possible to lose type safety with some constructs without the compiler warning you about it at all. The third party typings for JS dependencies are also often not a 100% correct, especially for rare code paths and edge cases. And due to how easy it is to fall back to any, there are also Typescript native libraries that don't uphold the guarantees they seem to give. Typescript is great, but it's far from bullet proof, and it's extremely frustrating to deal with bugs that the type system supposedly should have prevented.

frenchyatwork 5y ago
Some of those issues can be remedied by linting rules (preventing unsafe use of any), but typing of dependencies can be a headache. Even 1st party typing and Typescript dependencies can regularly be wrong if type safety was not important to whoever wrote them.
- mirekrusin 5y ago
  Absolutely, some of linter rules are very useful, ie. type-aware ones.
mirekrusin 5y ago
We're lucky where no- or very shallow- dependencies for our backend services are possible. I hear from collegues it's different world on f/e. It's true there are tons of poor quality libraries - both in pure js and ts. We try to avoid this transitive dependency explosion nonsense alltogether. Even well known libraries like lodash, which are not typescript first – are simply too dynamic. If ts doesn't offer precise types on functions – we avoid those. From our experience it looks like it pays off well to put an extra effort to guarantee that static types are correct and precise – no dependencies or trimmed to absolute minimum, rely on ts first code (usually ours), no dynamic fiddling that can't be expressed in ts, no any, no pretending via casting/non-null assertions, parsing/runtime-assertions on io-boundaries etc. Together with other techniques like branded types typescript can enter critial systems in enterprices – areas where js would never be allowed to exist. As you say it requires discipline – but I wouldn't call it "a lot", not in our case at least, the effort/benefit ratio is no-brainer in our case and at the end – it's honestly very pleasant language to work with.