Hacker News Reader

Comment by nine_k | Hacker News Reader

But do you see any reason why such tooling could not be built?

I suppose it's mostly an under-investment of time, not a shortcoming of the format itself.

Might it be though? Protobuf's tooling seems like a byproduct of the fact that you can't read protobuf and it's strict and type safe enough that you can generate lots of things.

Ion is readable and (seemingly) not very strict about schema. Seems like that would not readily incentivise additional tooling.

Protobuf can be converted to (and from) JSON for readability

Protobuf actually has a canonical text format. It's easy to produce in C++ or Java https://developers.google.com/protocol-buffers/docs/referenc...

The format has much less extra syntactical noise than JSON.

For example,

    name: "vii"  # comments allowed!
    id: 23923373

Pretty nifty as it allows readable configuration files with structured data.

if it is an "easy to produce or consume in language X" it does not mean it is canonical - it means that language X has an extension that allows to do so. Is there a place in protobuf spec or documentation mentioning this to be a part of the protocol?

Language X is at least C++ (as linked), Java https://developers.google.com/protocol-buffers/docs/referenc... , and Python https://github.com/protocolbuffers/protobuf/blob/master/pyth...

I think the Protobuf spec focuses on the binary serialization - the text format and JSON representations are not related to that at all, of course.

If you're working against a schema that means presumably there is a schema, and that defeats essentially the whole purpose of using a self-describing format like Ion. At that point, use something like protobuf that is schema-ful.

Reply on news.ycombinator.com