4 ms·

Can't speak for the GP but my single biggest complaint about TS is how it's basically a massive set of assumptions layered on top of JS. If the JS types at runt

by Merad 6y ago

Can't speak for the GP but my single biggest complaint about TS is how it's basically a massive set of assumptions layered on top of JS. If the JS types at runtime don't align with your assumptions in TS, the whole house of cards can come crashing down.

smichel17 6y ago
This is why you need input validation. Eg, zod or io-ts.
- cjdell 6y ago
  Did not know about these. I wrote my own a while back because I couldn't find an example of this being done (fully type safe validation). https://github.com/cjdell/type-safe-validator https://github.com/cjdell/type-safe-validator
  - buu700 6y ago
    Not exactly the same thing, but protobuf.js also works really well for this: https://github.com/protobufjs/protobuf.js https://github.com/protobufjs/protobuf.js
52-6F-62 6y ago
Which is the nature of the compiler. It maintains the promise that what you're writing is still JavaScript—in that you could just strip all the type annotations and have valid JS. But I would love runtime checks for types. Even if that was a compiler step I could flag on—but that makes it a great deal more complex both to implement and reason about, likely—without starting fresh anyway.
- phpnode 6y ago
  A while ago I built this exact mechanism for Flow, it could be done in TypeScript if there was enough demand for it (it's rather a large effort) https://gajus.github.io/flow-runtime/ https://gajus.github.io/flow-runtime/
- vorticalbox 6y ago
  I was thinking about this the other day i would love for TS flag that would turn an interface into an assert const shout = (message: string) => console.log(message) into something like const assert = require('assert'); const shout = (message) => { assert(typeof message === "string"); console.log(message); } of course this doesn't work for more complicated types
  - IggleSniggle 6y ago
    You should checkout myzod, which is very close to this experience.
    - colinmcd 6y ago
      Or just plain zod
      - IggleSniggle 6y ago
        Genuinely curious, why would you pick zod over myzod?
    - vorticalbox 6y ago
      Thanks for this
- mypalmike 6y ago
  Why do you need runtime type checks if the compiler already checked the type? IMO, runtime type analysis is a code smell. There are few scenarios where the simpler and more efficient solution involves querying type metadata at runtime. Particularly in a language that directly supports dynamic dispatch, you should think hard before adding anything resembling an "if typeof(mything)" check.
  - wolfgang42 6y ago
    The obvious use case is the interface between something that’s not type-checked by the compiler and something that is. It’d be useful to be able to do `runtime_cast<Foo>(JSON.parse(foo_json))` on, say, the response to an API call and know that the result was definitely a valid Foo without having to write a bunch of boilerplate to validate that by hand. (Reading through the thread, there’s apparently some libraries that can do this; I’ll have to try them out next time I need this.)
  - int_19h 6y ago
    Because there's no guarantee that compiler did that. Even if you do this in your code, the moment it gets called from pure JS, all bets are off. With proper runtime checks, you could get consistent behavior out of that.
DougBTX 6y ago
At the end of the day, if you look at a low enough level in the stack, there are no types. In a very concrete way, types are a high-level idea, and if the high-level stops matching the low-level, then bugs crop up. See for example Tetris implemented in Pokémon Yellow via runtime code injection: https://www.youtube.com/watch?v=Vjm8P8utT5g https://www.youtube.com/watch?v=Vjm8P8utT5g Their compiler missed that! So I think there's good reason to switch from talking about types as "assumptions", and think of them as compile time "assertions". Something lower-level in the stack could break the high-level code, but that doesn't make the high-level code useless, just imperfect.
- cjdell 6y ago
  I get what you're saying however even at the machine code level there is a difference between an i32 and an i64. Also the "sizeof" of a struct is important too when calculating how far to stride with regard to memory addresses. Types can and do affect the way programs run at the lowest level. Perhaps someone with a better understanding of compiler theory can elaborate further on this...

by Merad 6y ago

smichel17 6y ago

This is why you need input validation. Eg, zod or io-ts.

cjdell 6y ago
Did not know about these. I wrote my own a while back because I couldn't find an example of this being done (fully type safe validation). https://github.com/cjdell/type-safe-validator https://github.com/cjdell/type-safe-validator
- buu700 6y ago
  Not exactly the same thing, but protobuf.js also works really well for this: https://github.com/protobufjs/protobuf.js https://github.com/protobufjs/protobuf.js

52-6F-62 6y ago

Which is the nature of the compiler. It maintains the promise that what you're writing is still JavaScript—in that you could just strip all the type annotations and have valid JS. But I would love runtime checks for types. Even if that was a compiler step I could flag on—but that makes it a great deal more complex both to implement and reason about, likely—without starting fresh anyway.

phpnode 6y ago
A while ago I built this exact mechanism for Flow, it could be done in TypeScript if there was enough demand for it (it's rather a large effort) https://gajus.github.io/flow-runtime/ https://gajus.github.io/flow-runtime/
vorticalbox 6y ago
I was thinking about this the other day i would love for TS flag that would turn an interface into an assert const shout = (message: string) => console.log(message) into something like const assert = require('assert'); const shout = (message) => { assert(typeof message === "string"); console.log(message); } of course this doesn't work for more complicated types
- IggleSniggle 6y ago
  You should checkout myzod, which is very close to this experience.
  - colinmcd 6y ago
    Or just plain zod
    - IggleSniggle 6y ago
      Genuinely curious, why would you pick zod over myzod?
  - vorticalbox 6y ago
    Thanks for this
mypalmike 6y ago
Why do you need runtime type checks if the compiler already checked the type? IMO, runtime type analysis is a code smell. There are few scenarios where the simpler and more efficient solution involves querying type metadata at runtime. Particularly in a language that directly supports dynamic dispatch, you should think hard before adding anything resembling an "if typeof(mything)" check.
- wolfgang42 6y ago
  The obvious use case is the interface between something that’s not type-checked by the compiler and something that is. It’d be useful to be able to do `runtime_cast<Foo>(JSON.parse(foo_json))` on, say, the response to an API call and know that the result was definitely a valid Foo without having to write a bunch of boilerplate to validate that by hand. (Reading through the thread, there’s apparently some libraries that can do this; I’ll have to try them out next time I need this.)
- int_19h 6y ago
  Because there's no guarantee that compiler did that. Even if you do this in your code, the moment it gets called from pure JS, all bets are off. With proper runtime checks, you could get consistent behavior out of that.

DougBTX 6y ago

At the end of the day, if you look at a low enough level in the stack, there are no types. In a very concrete way, types are a high-level idea, and if the high-level stops matching the low-level, then bugs crop up. See for example Tetris implemented in Pokémon Yellow via runtime code injection: https://www.youtube.com/watch?v=Vjm8P8utT5g https://www.youtube.com/watch?v=Vjm8P8utT5g Their compiler missed that! So I think there's good reason to switch from talking about types as "assumptions", and think of them as compile time "assertions". Something lower-level in the stack could break the high-level code, but that doesn't make the high-level code useless, just imperfect.

cjdell 6y ago
I get what you're saying however even at the machine code level there is a difference between an i32 and an i64. Also the "sizeof" of a struct is important too when calculating how far to stride with regard to memory addresses. Types can and do affect the way programs run at the lowest level. Perhaps someone with a better understanding of compiler theory can elaborate further on this...