Hacker News new | ask | show | jobs
by colanderman 3612 days ago
I've never looked at proto3, but proto2 has at least the following issues:

* No clue about namespacing. If you pick the wrong name for something, you can have name clashes within a protobuf, across uninterpreted option classes, with protobuf source code, with your own source code; and it's different if you're in Python or C. Nowhere are naming restrictions defined.

* The API is maddening and inconsistent, especially in Python. (It's totally different between Python and C.) Some things look like lists but really aren't (e.g. you can't assign a list to a repeated field in Python). Even basic reflection (e.g. to get at uninterpreted options) is a Lovecraftian nightmare, and the docs are wholly unhelpful.

* Good luck serializing a list. There's not really such a thing, despite that the API pretends like there is; there are only repeated fields. So you need a separate flag to distinguish "empty list" from "not present list".

* Abstruse implementation. There are so many layers of indirection in the generated source and the core library that I wouldn't know where to start debugging.

Not sure if they fixed any of these issues with proto3.

1 comments

The short answer is the Python implementation wasn't exactly great.
Reflection in the C++ version is as bad or worse given that you can't mess around with it in a REPL to figure out how it really works. And the C++ version has most of the namespacing issues (e.g. any field starting with "set_" has potential to clash with another field).

Both implementations are equally bad, despite that they seem to have been written by two separate teams that didn't communicate with each other.

Honestly, I never had much trouble with the C++ one.