4 ms·
> The idea of "type safety over the network" is a fiction > When it comes down to it, what is being sent over the network is 1s and 0s ? When it comes down t
by rappatic 1y ago
> The idea of "type safety over the network" is a fiction
> When it comes down to it, what is being sent over the network is 1s and 0s
?
When it comes down to it, all of computing is 1s and 0s. This is not some feature that's particular to the wire.
- lblume 1y agoThe difference being that a client can be malicious, while e.g. a local file is assumed to behave with the same intent as another. Programs that run on one computer can always be statically verified, while the task is harder for server-client applications — the client could always be an untrusted impersonator!
- JadeNB 1y ago> The difference being that a client can be malicious, while e.g. a local file is assumed to behave with the same intent as another. I'm not sure what it means to assume something about the behavior of a file, presumably thought of as a static piece of data, but I'd certainly disagree that a modern computing system is entitled to assume that all local apps behave with the same intent as one another (except to the extent that it assumes that all local apps behave maliciously).
- munchler 1y agoThis happens with local files also, and was originally called “DLL hell”. The mismatch isn’t malicious, but the effect is the same.
- sophacles 1y agoA local file can be "newly local" and have recently been saved from the network or via a usb drive, etc. And assuming a file is going to behave with good intent, or even the same intent as another file of the same format, is bad. It's how we get jpeg/png/etc parsing errors. Its how we end up with PDFs that are also valid executables, and 1000 more issues.
- denkmoon 1y agoWhat does that have to do with type safety though? If anything, type safety improves whichever piece of the puzzle you do have control over by reducing the likelihood of you accepting malformed data.