(2) is explicitly one of the reasons to use proto3 over proto2, though :) It's weird seeing it listed as a disadvantage instead of the other way around.

Depends on the use case. For instance if you're mapping the data to database, you can't send null variables. Or you store the defaults (waste of space) or you send it as another type.

In our case we've now over 1T of rows. Storing default variables would be incredibly inefficient and expensive.

I'm not understanding your case much. Proto3 does not serialize zeros/false, precisely because it'd be a waste without a benefit. After deserialization, the value is as equal to zero as if the zero had been written on the wire or on disk. Why would you want to store that?

Is nullability of primitive types what you're missing? As in, having a boolean value that can be true, false, or null. If you need that, defining your field as google.protobuf.BoolValue instead of bool gives you that (same with the other primitive types: https://github.com/google/protobuf/blob/master/src/google/pr... ). But making primitive types never null aligns proto3 with most programming languages, making the generated code more idiomatic and performant.

Thanks. Those are pretty significant advantages. These things should be on the home page of the project. That's how smaller projects gain share.

The first one is, but as the obviously hyperbolic "infinitely faster" claim.

I use protobuf-generated RTTI for the purpose of doing endpoint SQL storage of the messages. (tables, columns, foreign keys, insert/select statements are all auto-generated from the protobuf message) using C++.

Does capnproto provide similar RTTI information to walk through properties or recurse into other messages?

Absolutely. I was the one who originally designed the Protobuf RTTI (aka "reflection") interface, after all... :)

It's actually considerably easier to implement for Cap'n Proto since the in-memory objects are actually backed by byte buffers containing the wire format. No need to compute offsets of class members (which technically violates the C++ standard though it works on all compilers).

re: "Doesn't encode/decode messages"

Does this mean that individual fields are encoded/decoded lazily?

Well, you could look at it that way. But the "encoding" is the same encoding that an "int" field in a struct uses, and "decoding" it is a trivial load instruction.

At what point is byte ordering handled?

The format is little-endian, so it's necessary to use a little-endian load instruction, which almost all architectures (including most big-endian architectures) have.

(But every widely-used arch these days is LE.)