Viewing profile — stepchowfun

Most of the comments so far are negative, so I'll add something positive. One thing I love about the Haskell community is how they are always questioning their assumptions and genu…

Thanks for your feedback!

If you're already familiar with a functional programming language like Haskell or OCaml, you have the background to work through my Coq tutorial here: https://github.com/stepchowfu…

For something a bit more lightweight, Toast: https://github.com/stepchowfun/toast

I think you're right, and now I understand why the rules seemed buggy to you but not to me. You're considering persisted messages that need to be compatible with many versions of t…

Asymmetric fields are in a temporary transition state to/from required. So it would seem a bit odd to me for the transition state to be the default. However, I think I see your rea…

> That's reasonable but it's a different notion of what a safe change is than I remember from using protobufs. I believe they just say adding or removing a required field isn't bac…

You're considering an alternative behavior for asymmetric fields in choices, but you need to consider the behavior of optional fields in choices too. In particular, the following d…

I can't speak with authority about ATD, but the following might be helpful: Aside from algebraic data types, the big selling point of Typical is asymmetric fields. That's the cruci…

If I understand you correctly, I believe your understanding is correct.

No IDL that supports required fields can offer the transitivity property you're referring to. Typical has no notion of commits or pull requests in your codebase. The only meaningfu…

If you add an asymmetric field to a struct, writers need to be updated to set the field for the code to compile . If you also add an asymmetric field to a choice, readers need to b…

A wasm port doesn't seem too farfetched. What's the use case for running the code generator in the browser?

I'd love for Typical to support Go! We'd need someone with enough time to implement it. If anyone is interested in contributing any code generators, you can start by copying the Ru…

Yes! We have comprehensive integration tests that run in the browser to ensure the generated code only uses browser-compatible APIs. Also, the generated code never uses reflection …

Avro has no equivalent of Typical's asymmetric fields. In Avro: 1. Record types can have optional (but not asymmetric) fields, just like in most IDLs. Avro implements this by takin…

It's a good question! The binary format is completely inscrutable to human eyes and is not designed for manual inspection/editing. However: 1) For Rust, the generated types impleme…

> If I have a single language codebase, why should I prefer the first approach? Probably the most compelling reason is that a single language codebase might not be a single languag…

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 a…

Typical creator here. I'm pleasantly surprised to find this on HN today! Happy to answer any questions about it.

This is a Typical concept. I haven't seen this approach to optionality for sum types in any other serialization framework. Programmers have good intuition for what it means for a f…