Hacker News Reader

Comment by Merad | Hacker News Reader

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.

View on HN

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

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

Not exactly the same thing, but protobuf.js also works really well for this: https://github.com/protobufjs/protobuf.js

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.

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/

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.

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.)

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.

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

You should checkout myzod, which is very close to this experience.

Thanks for this

Or just plain zod

Genuinely curious, why would you pick zod over myzod?

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

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.

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...

Reply on news.ycombinator.com