Hacker News Reader

Comment by galkk | Hacker News Reader

After working (internally) with Ion and related tooling, I'd say that I was opposite of fan. Protobuf strength is in good tooling/codegen around it (especially inside of Google), and with Ion you just have "superset of json".

Ion never had nice code wrappers around serialized structures, and most of the time, especially with rich structures it was frustrating experience.

View on HN

In 2013 I was generating code from SDL definitions which could also be used for data validation during serialization/deserialization. I had plenty of “model” packages which were just SDL definitions, build config, and maybe some unit tests to validate the schema constraints. (Edit: SDL is “schema definition language” which was a schema definition tool written for Ion with definitions in Ion.)

These were used in services and reactors which never touched raw Ion (at least not in any way different from Coral or BSF).

Full disclosure, I spent a lot of my free time working on Ion, both the supported implementations as well as my own. The additional data types are worth it alone, imho. Having to use JSON for most things now I’m frustrated at what is “missing”.

I built the first version of IntelliJ plugin[1] to make working with the reactor stuff easier. Doesn't look like there have been much improvements to it.

1: https://github.com/amzn/ion-intellij-plugin

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