Re:Typical: Data interchange with algebraic data types
by stepchowfun on Sunday May 21, 2023 @08:44PM
(#36026128)
You're exactly right about other frameworks appealing to the lowest common denominator, whereas Typical isn't willing to make such compromises.
Languages without proper sum types are at a disadvantage here, but it's possible to encode sum types with exhaustive pattern matching in such languages using the visitor pattern. That approach requires some ergonomic sacrifices (e.g., having to use a reified eliminator rather than the built-in `switch` statement), and people using those languages may prefer convenience over strong guarantees. It's an unfortunate impedance mismatch.
Re:Typical: Data interchange with algebraic data types
by jcparkyn on Monday May 22, 2023 @02:58AM
(#36028275)
I'd imagine that most people voluntarily using go or similar languages wouldn't be too bothered by just having all the checks occur at runtime in the generated code, rather than encoding them in the type system.
Sum types are still awkward, but most languages can at least approximate them, minus some compile-time checks.
And now that I think about it, Protobuf/Thrift/etc type tools are heavily constrained by finding lowest-common-demoninator of language features to allow for cross serialization. Maybe in the next generation of these tools, languages like golang don't get a seat at the table for the sake of progress -- I could be fine with it.