It's not quite clear to me why you'd use this over something more established such as protobuf, thrift, flatbuffers, cap n proto etc.
This lib keeps the compact representation at runtime and lets you read it without putting all the entities on the heap.
Cool!
It falls down if you have e.g. an array of 1 million small items, because you still need to skip over 999999 items to get to the last one. It looks like RX adds some support for indexes to improve that.
I was in this situation where we needed to sparsely read huge JSON files. In the end we just switched to SQLite which handles all that perfectly. I'd probably still use it over RX, even though there's a somewhat awkward impedance mismatch between SQL and structs.
It's not like you can just tell them to move to protobuf.
If you are working with an end you don’t control, this “newer better” format isn’t in your cards either.
RX can represent any value JSON can represent. It doesn't even lose key order like some random-access formats do.
In fact, RX is closer to JSON than CBOR.
Take decimals as an example:
JSON numbers are arbitrary precision numbers written in decimal. This means it can technically represent any decimal number to full precision.
CBOR stores numbers as binary floats which are appriximations of decimal numbers. This is why they needed to add Decimal Fractions (Tag 4)
RX already stores as decimal base and decimal power of 10. So out of the box, it matches JSON