3 ms·

I still think that JS is very much not TS. Most TS code assumes you never need to check for errors because the type checker proves they can't happen. Then, par

I still think that JS is very much not TS. Most TS code assumes you never need to check for errors because the type checker proves they can't happen. Then, paradoxically, with no error checking at runtime, it becomes fully possible for JS code to call into TS code in a way that breaks the shit out of the TS compiler's assumptions. In philosophy then TS and JS are as incompatible as GPL and EULA

epolanski 11mo ago
The type checker can only prove what is known at compile time and only if you're disciplined. To bridge runtime and compile time (as your application will likely get some external data) you've got to use a proper parser such as zod[1] or if you want to stretch it even further effect-schema[2]. [1] https://zod.dev/ https://zod.dev/ [2] https://effect.website/docs/schema/introduction/ https://effect.website/docs/schema/introduction/
- girvo 11mo ago
  I’m currently in love with Arktype, and as it supports Standard Schema it plugs into most places that can take Zod schemas too :) https://arktype.io/ https://arktype.io/
  - epolanski 11mo ago
    That's a validator, not a proper parser, no?
    - culi 11mo ago
      What's the difference here? I've only used Zod but I typically think of Zod as a runtime validation library. AFAIK arktype is a full-featured replacement for Zod
    - girvo 11mo ago
      I don't think I understand the difference you're drawing on here? It parses data and validates its structure, and is a replacement for all my uses of Zod?
md224 11mo ago
Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though. Dealing with external input requires type assertions (since Typescript doesn't know what the program is getting at compile-time) and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript. However, if your point is that Typescript can lull people into a false sense of safety, then sure, I take your point. You have to understand where type assertions are coming into play, and if that's obscured then the type safety can be illusory. The benefits of Typescript require you to make sure that the runtime inputs to your program are sufficiently validated.
- conartist6 11mo ago
  TS certainly thinks of external input as a boundary requiring safety, but usually that would mean form input or CLI args parsing or something. Usually there's little if any protection against a JS caller providing wrong-type args to TS functions.
  - md224 11mo ago
    Sure, but if the caller is Javascript then you're running Javascript, not Typescript*, so it makes sense that you're not going to get type safety. I'm also not sure we're actually disagreeing on anything, so perhaps my reply was pointless. I agree that if you mix JS and TS in the way you describe, you'll have problems. My reply was just to say "yes, and that's not really Typescript's fault", but perhaps you weren't implying that to begin with. * I'm aware that you can't run Typescript directly, but I hope my point here is clear... you're running a program that wasn't type-checked by TS.
    - conartist6 11mo ago
      I don't think we're disagreeing either. I didn't mean to suggest that it was Typescript's fault, just that the relationship between TS and JS in theory is something like "TS is a superset of JS" but once you get down to the practice of writing idiomatic reusable code it's more like TS and JS are fully different languages.
sethaurus 11mo ago
It doesn't matter if a library is written in TS or JS; you cannot meaningfully protect against other code calling you incorrectly. Sure, you can check if they gave you a string instead of a number. But if you receive an array of nested objects, are you going to traverse the whole graph and check every property? If the caller gives you a callback, do you check if it returns the correct value? If that callback itself returns a function, do you check that function's return type too? And will you check these things at every single function boundary? This kind of paranoid runtime type-checking would completely dominate the code, and nobody does it. Many invariants which exist at compile-time cannot be meaningfully checked at runtime, even if you wanted to. All you can do is offer a type-safe interface, trust your callers to respect it, and check for a few common mistakes at the boundary. You cannot protect your code against other code calling it incorrectly, and in practice nobody does. This is equally true for JS and TS.

epolanski 11mo ago

The type checker can only prove what is known at compile time and only if you're disciplined. To bridge runtime and compile time (as your application will likely get some external data) you've got to use a proper parser such as zod[1] or if you want to stretch it even further effect-schema[2]. [1] https://zod.dev/ https://zod.dev/ [2] https://effect.website/docs/schema/introduction/ https://effect.website/docs/schema/introduction/

girvo 11mo ago
I’m currently in love with Arktype, and as it supports Standard Schema it plugs into most places that can take Zod schemas too :) https://arktype.io/ https://arktype.io/
- epolanski 11mo ago
  That's a validator, not a proper parser, no?
  - culi 11mo ago
    What's the difference here? I've only used Zod but I typically think of Zod as a runtime validation library. AFAIK arktype is a full-featured replacement for Zod
  - girvo 11mo ago
    I don't think I understand the difference you're drawing on here? It parses data and validates its structure, and is a replacement for all my uses of Zod?

md224 11mo ago

Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though. Dealing with external input requires type assertions (since Typescript doesn't know what the program is getting at compile-time) and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript. However, if your point is that Typescript can lull people into a false sense of safety, then sure, I take your point. You have to understand where type assertions are coming into play, and if that's obscured then the type safety can be illusory. The benefits of Typescript require you to make sure that the runtime inputs to your program are sufficiently validated.

conartist6 11mo ago
TS certainly thinks of external input as a boundary requiring safety, but usually that would mean form input or CLI args parsing or something. Usually there's little if any protection against a JS caller providing wrong-type args to TS functions.
- md224 11mo ago
  Sure, but if the caller is Javascript then you're running Javascript, not Typescript*, so it makes sense that you're not going to get type safety. I'm also not sure we're actually disagreeing on anything, so perhaps my reply was pointless. I agree that if you mix JS and TS in the way you describe, you'll have problems. My reply was just to say "yes, and that's not really Typescript's fault", but perhaps you weren't implying that to begin with. * I'm aware that you can't run Typescript directly, but I hope my point here is clear... you're running a program that wasn't type-checked by TS.
  - conartist6 11mo ago
    I don't think we're disagreeing either. I didn't mean to suggest that it was Typescript's fault, just that the relationship between TS and JS in theory is something like "TS is a superset of JS" but once you get down to the practice of writing idiomatic reusable code it's more like TS and JS are fully different languages.

sethaurus 11mo ago

It doesn't matter if a library is written in TS or JS; you cannot meaningfully protect against other code calling you incorrectly. Sure, you can check if they gave you a string instead of a number. But if you receive an array of nested objects, are you going to traverse the whole graph and check every property? If the caller gives you a callback, do you check if it returns the correct value? If that callback itself returns a function, do you check that function's return type too? And will you check these things at every single function boundary? This kind of paranoid runtime type-checking would completely dominate the code, and nobody does it. Many invariants which exist at compile-time cannot be meaningfully checked at runtime, even if you wanted to. All you can do is offer a type-safe interface, trust your callers to respect it, and check for a few common mistakes at the boundary. You cannot protect your code against other code calling it incorrectly, and in practice nobody does. This is equally true for JS and TS.