[cartoffal]

In many statically-typed languages, types do not exist at runtime - they are erased once the program is known to be internally consistent. What is left is not type safety, it is parsing and validation of unstructured binary blobs (or arbitrary strings, depending on the protocol) into structured data. Structure and types are not the same thing, and in many languages they barely even overlap.

[setr]

Any input data has the same problem. Type safety exists after validation, and its guarantees hold only if your original validation was upheld.

Files, database, user input, network protocols, etc. I don’t know why the network would be any way special. You parse/validate unstructured binary blobs into structured data, and what’s left is type safety. It’s not in the runtime only because, if the compiler has done its job correctly, it is typesafe by construction.

In other words, how many times are you going to check your data structure is correct, before you start assuming it’s correct? Once — at parsing and validation — after that, you’re working with structured data, and your types are just recording the fact

[cartoffal]

> I don’t know why the network would be any way special.

The network isn't special. This applies locally too. But the article we are commenting on (at least, _I_ was commenting on) is about the network, and it uses the phrase "type safety over the network" in particular.

> You parse/validate unstructured binary blobs into structured data, and what’s left _is type safety_.

That is in fact exactly what I said. The point is that at some point you started with unstructured binary blobs. As soon as data leaves the application, it is no longer "safe", and it is unsafe until it is ingested and (re)validated. So my point can be freely generalised to "type safety beyond the application boundary is a fiction". And the application boundary will always exist, whether you are working with a strongly or weakly, statically or dynamically typed language.