> Protobuf and flatbuffers have different use cases in my experience, although that's somewhat limited.

This is true for the ASN.1 encoding rules as well.

> Protobuf at least also introduced breaking changes between versions 2 and 3. ASN.1 isn't perfect in this regard,

When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code.

▲ memling 3 months ago | parent [-]

> When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code.

Good question. I was thinking of the transitions in the '80s, although my experience with standards written during that time is very limited.

But yes, one of the reasons people use ASN.1 is because of its hard and fast commitments to backwards compatibility.

▲ cryptonector 3 months ago | parent [-]

> But yes, one of the reasons people use ASN.1 is because of its hard and fast commitments to backwards compatibility.

To be fair I think that's generally expected of things like it. XDR? Stable. DCE/RPC? Obsolete, yes, but stable. MSRPC? A derivative of DCE/RPC, and yes, stable. XML? Stable. JSON? Stable. And so on. All of them stable. If PB broke backwards-compat once then to me that's a very serious problem -- details?

	▲	memling 3 months ago \| parent [-]
		> If PB broke backwards-compat once then to me that's a very serious problem -- details? Proto2 and Proto3 differ in how they handle default and required elements. Regarding these differences, I found a few references online: `https://softwareengineering.stackexchange.com/questions/350443/why-protobuf-3-made-all-fields-on-the-messages-optional https://groups.google.com/g/protobuf/c/Pezwn5UYZss https://www.hackingnote.com/en/versus/proto2-vs-proto3/` I don't use protobuf regularly, and they claim that the wire formats are bidirectionally compatible. When I last evaluated them with another developer years ago, I don't recall this being the case. (It was not merely a difference between their syntaxes.) I'm not sure the semantics are preserved between the two versions, either (e.g., did I provide a default value? was this element optional and missing? etc.). They have lately (this is news to me) moved to protobuf editions: https://protobuf.dev/editions/overview/. This provides some flexibility in the code generation and may require some maintenance on the part of the user to ensure that codec behavior remains consistent. Google, for their part, are trying to minimize these disruptions: > When the subsequent editions are released, default behaviors for features may change. You can have Prototiller do a no-op transformation of your .proto file or you can choose to accept some or all of the new behaviors. Editions are planned to be released roughly once a year.