Hacker News Reader

Comment by jasonzemos | Hacker News Reader

> I suppose it depends what you are comparing it to. Almost every JSON library has the same limitations you mentioned, and yet many people find JSON useful for network applications.

JSON is a human-readable format which is hugely advantageous to develop and operate in many settings. Protobufs doesn't have that advantage. Yet we're paying all of the same costs to structure the data with both. That's enough to posit JSON as a net winner over protobufs.

> Unfortunately protobuf C++ can't live fully within this arena model while it uses std::string for accessors.

Forcing std::string as a container for core components of a networking API (specifically for an accessor) is an exemplary demonstration of a lack of seriousness in a library.

View on HN

You can debate the design decisions all you want (and I agree `std::string` was a poor choice here)... but it's kind of absurd to say that a technology underpinning products used by billions of people every day is not "serious".

Why is that absurd? Products used by billions of people may just as well not have serious requirements. I beg not to debate semantics, indeed my own fault, but in the world of network software requirements can start to get very serious, straight through to userspace protocol stacks on DMA'ed device buffers.

Would you go through all of the effort to rig an application with userspace networking only to return its results inside an `std::string` -- one of the few std containers where one can't even control the allocator if they wanted to? That's absurd, if anything.

> but in the world of network software requirements can start to get very serious, straight through to userspace protocol stacks on DMA'ed device buffers.

Google does all of that when it makes sense, and yet uses it to push protobufs. That’s the entire point: you are calling it absurd and non-serious, but this only shifts my opinion on you, not on Google.

If you are arguing that there exist use cases for which Protobuf is ill-suited, then fine, I obviously agree.

But you seem to be arguing that Protobuf is bad because it is not well suited to certain use cases, dismissing all other use cases as "non-serious". That is offensive.

I asked you not to argue semantics, but you're doing it anyway. I didn't respond here to argue protobufs actually is bad, since all software is suited to something for somebody somewhere.

In fact, I can just do that now: Protobufs is bad. You seem to agree, because you haven't even advocated for it -- just flatbuffers and Cap'n Proto and the phonebook of alternatives. Listen, I don't care who you've worked for or what you've done. As a scientist and engineer I'm totally ready and able to entertain critiques of my prior works without being offended. I'm offended that this is the quality of your participation here.

This is a really unprofessional and unreasonable approach (and I can see you're being downvoted for it). Since you say you're a scientist and engineer, can you share your prior work so we can evaluate it?

> Forcing std::string as a container for core components of a networking API (specifically for an accessor) is an exemplary demonstration of a lack of seriousness in a library.

im not super experienced with c++, so please forgive the maybe obvious question, but why is that?

(im guessing it has to do with allowing control over where allocations come from?)

In general I agree although I think it's fair to separate the protobuf wire format from the proto3 schema format which had a canonical json representation.

Reply on news.ycombinator.com