Static type systems are just a tool. The type signature describes what _your_ module is capable of handling. If other modules pass incorrect data, your module w

Static type systems are just a tool. The type signature describes what _your_ module is capable of handling. If other modules pass incorrect data, your module will fail, whether statically or dynamically typed, albeit harder to debug in the dynamically typed case. If every field ends up being truly optional, it's going to be hard to change your module, because of the sheer weight of the combinatorial explosion of field subsets that may or maynot be set when third party modules interact with your module. Most of the time optional fields: * Encode that your module doesn't care about such-and-such fields, so the parser / type checker should just ignore them. * Are used to encode variants of the same data that slightly changed in another module [id changed from number to string], so you should use an union type. In practice, designing a statically typed ecosystem for wire data is hard [0]. Grpc has basically gave up on validating field presence altogether [1]. These failures are directly caused by the immaturity of the ecosystem [deep decode batches of unrelated messages in middleware, WTF?]. It would be a mistake to throw the baby with the bathwater and blame the mathematically sound idea that your module can only process data of a certain shape, encoded by a suitable type signature. [0] https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers https://capnproto.org/faq.html#how-do-i-make-a-field-require... [1] https://github.com/protocolbuffers/protobuf/issues/2497#issuecomment-267422550 https://github.com/protocolbuffers/protobuf/issues/2497#issu...