Protobuf's original sin was failing to distinguish zero/false from undefined/unset/nil. Confusion around the semantics of a zero value are the root of most proto-related bugs I've come across. At the same time, that very characteristic of protobuf makes its on-wire form really efficient in a lot of cases.

Nearly every other complaint is solved by wrapping things in messages (sorry, product types). Don't get the enum limitation on map keys, that complaint is fair.

Protobuf eliminates truckloads of stupid serialization/deserialization code that, in my embedded world, almost always has to be hand-written otherwise. If there was a tool that automatically spat out matching C, Kotlin, and Swift parsers from CDDL, I'd certainly give it a shot.

Agreed the CDDL to codegen pipeline / tooling is the biggest thing holding back CBOR at the moment.

Some solutions do exist like here’s a C one[1] which maybe you could throw in some WASI / WASM compilation and get “somewhat” idiomatic bindings in a bunch of languages.

Here’s another for Rust [2] but I’m sure I’ve seen a bunch of others around. I think what’s missing is a unified protoc style binary with language specific plugins.

[1] https://github.com/NordicSemiconductor/zcbor

[2] https://github.com/dcSpark/cddl-codegen

> Protobuf's original sin was failing to distinguish zero/false from undefined/unset/nil.

It's only proto3 that doesn't distinguish between zero and unset by default. Both the earlier and later versions support it.

Proto3 was a giant pile of poop in most respects, including removing support for field presence. They eventually put it back in as a per-field opt-in property, but by then the damage was done.

A huge unforced mistake, but I don't think a change made after the library had existed for 15 years and reverted qualifies as an "original sin".