The author uses the term "union", but unfortunately they picked the one wrong term against a long list of correct alternatives: sum type, tagged union, discriminated union, coproduct, disjoint union, variant, algebraic data type, ...
"Union" does not imply disjointness (which is the source of many problems), whereas all those other terms do.
Correct, I just continued to use the term of OP. Sum types r coproducts are what I mean.
By the "author", I meant the author of the article. I figured you were just being consistent with them.
You’re probably thinking of C/C++ unions, and they do indeed have quite tricky semantics and are difficult to use correctly. What the article and the other commentators are talking about is more properly called a “sum type”, like Rust’s enums, for instance. Those are different things from C unions. In languages with first class support for sum types, they are used everywhere, it’s an incredibly useful concept.
Gotcha, ta. That becomes a tricky problem when we're talking about something that's primarily a storage engine though, right?
Not sure - because in the end, a programming language also has to store this concept in memory. I don't think there is a fundamental difference.
Well, sum types are not magic - they must be stored in the memory somehow. Rust's enums tend to use a simple approach: there's a large enough integer tag (usually an 8-bit integer), followed by enough space to store any of the variants. The same exact encoding could be used with a database storage engine too.
Not at all. Untagged unions, sure, but no decent modern language has first-class support for untagged unions. First-class tagged unions are a real treat to use.