Hacker News Reader

Comment by Dr_tldr | Hacker News Reader

But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime?

Certainly type checking can prove that it's the right type, but in my experience knowing that it's the right type but the wrong data is useless, I care if it's the exact data it's supposed to be.

How does type checking protect you (or someone else) from inadvertently mutating a value without changing it type and causing problems later? It's perfectly possible to do this without having any checks for class/instance throw a warning, unless there's something I'm missing.

View on HN

> But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime?

Sure, but that's what happens in every other language e.g. C's type system will enforce certain properties for you but when you compile to machine code the machine code is not checking those properties at runtime. If you know the compiler is correct you don't have to worry.

Nobody is saying you should stop writing tests but a good type system will mean you have to write less tests because the type system will do some of the checking for you in a more robust way.

Q: What is a concrete advantage of Typescript?

A: C's type system is very useful for data validation.

Please read at least one sentence before writing a response next time.

You claimed that the lack of type checking at runtime is somehow detrimental to the notion. He pointed out that, fundamentally, all strongly typed languages run as weakly typed machine code at runtime, giving C as one obvious example. Thus, types in TS are at least as useful as types in C.

The concrete advantage of TS is the same as the concrete advantage of any strongly typed language - types let you do static validation, and unlike tests, they allow for that validation to be provably complete (of course, the domain of constraints that can be so validated depends on the power of the type system in question).

Yes, but what about mutating objects/primitives in a way that causes all validations to pass but still be passing the wrong data?

It seems like using type checking as a reason to write fewer tests actually just creates nastier bugs in areas where your coverage is based on type validation.

What am I missing about checking type mutation !== mutation being a problem?

What is the advantage of strong types if your data structures are immutable? Is there any? I'm genuinely trying to understand if TS is just for cases where uncontrolled mutation is the norm and test coverage is poor.

Immutability is also something you can model in the type system (not currently in Typescript, but it is possible in other languages).

That said, immutability by itself won't save you from passing the wrong shape of immutable object into a function, just as validating the shape of the argument passed and the argument expected against each other won't help if there are other assumptions being made by the code (such as that the object cannot be mutated). As one of the parent comments pointed out, types are proofs. Not everything can be proved to a compiler, but (assuming a bug-free compiler) everything which can be proved to a compiler does not need any additional tests. Things which cannot be proved to a compiler will need tests, of course.

> Yes, but what about mutating objects/primitives in a way that causes all validations to pass but still be passing the wrong data? > What is the advantage of strong types if your data structures are immutable? Is there any? I'm genuinely trying to understand if TS is just for cases where uncontrolled mutation is the norm and test coverage is poor.

Can you give an example? I'm not following what you mean. Why would strong types be less useful if your data structures are immutable? OCaml mostly uses immutable data structures for example but its strong type system is fundamental to why it can be used to write such robust code.

Typescript has a stronger type system than JavaScript so Typescript can therefore capture more program properties statically compared to JavaScript whether you're using mutable data structures or not.

> knowing that it's the right type but the wrong data is useless, I care if it's the exact data it's supposed to be

Entirely possible people are comparing apples to oranges here. My experience is all based on structured data; e.g. User, Address, Order, Product, etc, and the relations between them. Data is generally static throughout the duration of the call; e.g. CRUD app.

It sounds like your experience is more with raw numbers and collections, and higher rates of entropy. In that case, I can see how types wouldn't add much value, and tests would be far more essential.

The whole point of strongly statically typed languages is that the proofs are performed at compile time. Statically typed programs shouldn't change behaviour after type erasure.

Languages with strong enough type systems can statically guarantee that data is structured correctly at runtime. Stronger structural requirements require stronger type systems. Algebraic data types are sufficient for many common static structuring guarantees.

It's all eventually compiled down to machine code, which doesn't have what you or I would call type checking.

You are correct, there is no type-checking at runtime. Getting garbage data where you are expecting properly formed data will throw a nasty wrench in your application.

Thankfully this rarely happens.

Reply on news.ycombinator.com