Hacker News Reader

Comment by regular_trash | Hacker News Reader

Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data.

Also, many built in functions do not have sufficient typesafey like Object.entries() for instance

View on HN

That is an issue with how TS works, but it can be significantly improved upon by using a library to verify the structure of deserialized data. zod is one example, or you could use protobufs. Fundamentally, this is an issue with any programming language. But having your base "struct"-like type be a hashmap leads to more mistakes as it will accept any keys and any values.

I disagree that this is an issue in every language - the problem is that in other languages the validation against some schema is more or less required for unmarshalling, and it's optional in TS.

Seeing a deserialization error immediately clues you in that your borders are not safe. Contrast that with TypeScript, where this kind of issue can lead to an insidious downstream runtime issue that might seem completely unrelated. This second scenario is very rare in other languages.

I don't know Rust, and I'm genuinely curious: How does it improve over that problem?

When you call a REST API (or SQL query for that matter), how does it ensure that the data coming back matches the types?

TS allows you to do parse the JSON, cast it into your target type, done (hiding correctness bugs, unless using runtime verification of the object shape, see sibling comment). Does Rust enforce this?

It validates the object shape at runtime, much like you can do in Typescript with a library like Zod. The key difference in this case is that Rust makes it scary to not validate data while Typescript will gladly let you YOLO it and blow your legs off, even in strict mode.

Okay I see, that's a nice secure-by-default point, whereas TS is arguably not secure-by-default.

It’s not. And trying to just be a transformation of the source to JS without its own standard library (mostly, some old stuff doesn’t follow this) means it really isn’t possible with just TS alone.

That’s OK with me. I use TS because I like it and hate the total lack of safety in JS. I have to use JS on the web, so TS it is.

If I don’t need it to run on a webpage, I wouldn’t be writing it in TS. I like other languages more overall.

The worst offender is toString which has different types between objects and is everywhere by default.

What do you mean by "safe" in this context?

If you type correctly at border of your system, then TS will be very close to a formal verification of your code. This won't catch all bugs, but even broad categories for you data is helpful. If you know your input is a non-null string. Then it will warn you of every non string usage. It won't catch whether it's a name or an email, but knowing someone tries to divide it by zero is helpful.

It's a lot more effort, but branded types for conceptual differences can bridge that last gap

Reply on news.ycombinator.com