I know everything reduces to bits eventually, but modern CPUs and memory aren’t as “lossy” as the network is, meaning you can make more assumptions about the data being and staying intact (especially if you have ECC).

Once you add distribution you have to encode for the fact that the network is terrible.

You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one field is corrupted, do you reject everything? Sometimes, but often Probably not, network calls are too expensive, so you encode that into the type with a Maybe. But of course any field could be corrupt so you have to encode lots of fields as Maybes. Suddenly you have reinvented dynamic typing but it’s LARPing as a static type system.

▲

jakelazaroff 3 hours ago | parent [-]

I think you can avoid most issues by not doing what you're describing! Ensuring data arrives uncorrupted is usually not an application-level concern, and if you use something like TCP you get that functionality for free.

▲

tombert 2 hours ago | parent [-]

TCP helps but only to a certain extent; it only guarantees specific ordering of bits during its session. Suppose you have to construct an object out of three separate transmissions, like some kind of multipart style thing. If one of the transmissions gets corrupted or gets errors out from TCP, then you still fall into that maybe trap.

▲

obsoleetorr 2 hours ago | parent [-]

so you need transactions?

I get what your saying, but can't you have the same issue if instead you have 3 local threads that you need to get the objects from, one can throw an exception and you only receive 2, same problem

▲

tombert 2 hours ago | parent [-]

Sometimes, but I am arguing that you need to encode for this uncertainty if you want to make distributed apps work correctly. If you can do transactions for what you’re doing then great, not every app can do that.

When you have to deal with large amounts of uncertainty, static types often reduce to a bunch of optionals, forcing you to null check every field. This is what you end up having to do with dynamic typing as well.

I don’t think types buy you much in cases with extreme uncertainty, and I think they create noise as a result.

It’s a potentially similar issue with threads as well, especially if you’re not sharing data between them, which has similar issues as a distributed app.

A difference is that it’s much cheaper to do retries within a single process compared to doing it over a network, so if something gets borked locally then a retry is (comparatively) free.

	▲	folex a minute ago \| parent [-]
		> static types often reduce to a bunch of optionals, forcing you to null check every field On one end, you write / generate / assume a deserialisator that checks whether incoming data satisfies all required invariants, eg all fields are present. On the other end, you specify a type that has all the required fields in required format. If deserialisation fails to satisfy type requirements, it produces an error which you can handle by eg falling back to a different type, rejecting operation or re-requesting data. If deserialisation doesn't fail – hooray, now you don't have to worry about uncertainty. The important thing here is that uncertainty is _contained_ in a very specific place. It's an uncertainty barrier, if you wish: before it there's raw data, after it it's either an error or valid data. If you don't have a strict barrier like that – _every place_ in the program has to deal with uncertainty. So it's not necessarily about dynamic / static. It's about being able to set barriers that narrow down uncertainty, and growing number of assumptions. The good thing about ergonomic typing system is that it allows you to offload these assumptions from your mind by encoding them in the types and let compiler worry about it. It's basically automatization of assumptions book keeping.