- 39comments
- 275comments
- 23comments
- 211comments
- 706comments
- 34comments
- 1comments
- 55comments
- 4comments
- 16comments
- 1comments
- 40comments
- 68comments
- 47comments
- 29comments
- 33comments
- 32comments
- 108comments
- 3comments
- 83comments
- 112comments
- 92comments
- 32comments
- 7comments
- 17comments
- 91comments
- 33comments
- 21comments
- 118comments
- 4comments
Cool. And the next enlightening step would be to generate custom parser code from message schemas. So that when de-serializer reads a next field, it does not read what name and type it will be, it expects and fails if it's not. Safer and more compiler friendly.
Congratulations, your strings dont support Unicode and you just ignored probably more than 3/4 or more of the world's languages.
Schemas save you space, but then you lose the ability to understand the data without the schema. That's where JSON has always been handy despite its inefficiencies.
Of course you can get the same kind of thing in binary. I wrote a drop-in binary JSON replacement because it's easy to write a binary one that's twice as fast as simjson and yyjson. The important thing is to never give the drop-in replacement any extras that break roundtrip compatibility.
Was a fun little project to write, and quite useful for me: https://github.com/kstenerud/bonjson
Of course that’s orthogonal to using a text v binary representation, you can have a schema’d text format, and a self-describing binary format.
BSON, UBJSON, MessagePack and CBOR are binary but self-describing.