4 ms·
The big thing I find that strict type aficionados get wrong is that it is immensely useful in practice to be able to read data that your program only needs to u
by unconed 4y ago
The big thing I find that strict type aficionados get wrong is that it is immensely useful in practice to be able to read data that your program only needs to understand a subset of, while still being able to reserialize it intact and pass it on.
It allows you to e.g. evolve systems in a backwards compatible way without having to update every single component in a pipeline in lockstep.
Most marshalling/unmarshalling systems can't do this.
- majewsky 4y agoCan you elaborate on which systems those are? Every one I've used so far can deal with incomplete types, either through a document-level or type-level escape hatch. For example, in Go, encoding/json has an option to DisallowUnknownFields that even defaults to false. And even if you enable that, there's the option of soaking up unknown object keys into a map[string]any member field on the level of each individual struct type.
- unconed 4y agoIt depends. Sometimes the marshalling layer doesn't support it, because it's directly unserializing to a native struct via codegen. Often the app 's other types are too rigid to carry extra hierarchical metadata along even if you did unserialize it. And often it's the devs themselves that are averse to anything not rigidly typed or capable of inconsistent or incomplete states, because it's less pure or ergonomic... even though being able to store an incomplete record as a draft is an affordance everyone needs. ie. doesn't matter if Go can unserialize like this if the devs on your team hate the idea