the tldr of this blog post is "today's invalid states are often tomorrow's feature requirements" and i found myself nodding along in agreement
i have encountered the "no optional fields on network messages" argument before, often from nominative type likers
but in practice, new fields are always optional: clients need to be able to downgrade requests to talk to old servers
and servers have to be able to upgrade old requests to avoid having 200 code paths
really you only have two types of network message: every field is optional
and the three or four cases where that's not true, like "vec3"
@tef i think you gotta take "make invalid states unrepresentable" along with "parse don't validate". malformed, transitional, incomplete, future/past variations, etc. are "valid states" from the point of view of interfacing with the world outside, but i think you can use type system methodology still to manage how you process those states into something more sanitized for your core business logic