From 9f06d422ef0e96eae830c4787a613f744aace3f4 Mon Sep 17 00:00:00 2001 From: Stephan Boyer Date: Fri, 5 Sep 2025 23:28:14 -0700 Subject: [PATCH] Reword an awkward sentence in the README --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 17808fb6..29180fd0 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ *Typical* is a [data serialization](https://en.wikipedia.org/wiki/Serialization) framework. You define data types in a file called a *schema*, then Typical generates efficient serialization and deserialization code for various languages. The generated code can be used for marshalling messages between services, storing structured data on disk, etc. The compact [binary encoding](#binary-encoding) supports forward and backward compatibility between different versions of your schema to accommodate evolving requirements. -Typical can be compared to [Protocol Buffers](https://developers.google.com/protocol-buffers) and [Apache Thrift](https://thrift.apache.org/). The main difference is that Typical has a more modern type system based on [algebraic data types](https://en.wikipedia.org/wiki/Algebraic_data_type), emphasizing a safer programming style with non-nullable types and exhaustive pattern matching. You'll feel at home if you have experience with languages that embrace this style, such as Rust and Haskell. Typical offers a new solution (["asymmetric" fields](#asymmetric-fields-can-safely-be-promoted-to-required-and-vice-versa)) to the classic problem of how to safely add or remove fields in [record types](https://en.wikipedia.org/wiki/Record_\(computer_science\)) without breaking compatibility. The concept of asymmetric fields also solves the dual problem of how to preserve compatibility when adding or removing cases in [sum types](https://en.wikipedia.org/wiki/Tagged_union). +Typical can be compared to [Protocol Buffers](https://developers.google.com/protocol-buffers) and [Apache Thrift](https://thrift.apache.org/). The main difference is that Typical has a more modern type system based on [algebraic data types](https://en.wikipedia.org/wiki/Algebraic_data_type), emphasizing a safer programming style with non-nullable types and exhaustive pattern matching. You'll feel at home if you have experience with languages that embrace this style, such as Rust and Haskell. Typical proposes a new solution (["asymmetric" fields](#asymmetric-fields-can-safely-be-promoted-to-required-and-vice-versa)) to the classic problem of how to safely add or remove fields in [record types](https://en.wikipedia.org/wiki/Record_\(computer_science\)) without breaking compatibility. The concept of asymmetric fields also solves the dual problem of how to preserve compatibility when adding or removing cases in [sum types](https://en.wikipedia.org/wiki/Tagged_union). In short, Typical offers two important features that are conventionally thought to be at odds: