Protobuffers Are Wrong (2018)
reasonablypolymorphic.com
Protobuffers Are Wrong (2018)
1–10 of 321 posts
Re: Protobuffers Are Wrong (2018)
#2I'm more than a little curious what event caused such a strong objection to protobuffers. :D
I do tend to agree that they are bad. I also agree that people put a little too much credence in "came from Google." I can't bring myself to have this much anger towards it. Had to have been something that sparked this.
Re: Protobuffers Are Wrong (2018)
#3Not even before the first line ends you get "They’re clearly written by amateurs".
This is a rage bait, not worth the read.
Re: Protobuffers Are Wrong (2018)
#4The author makes good arguments; I wish they'd offered some alternatives.
Despite issues, protobufs solve real problems and (imo) bring more value than cost to a project. In particular, I'd much rather work with protobufs and their generated ser/de than untyped json
Re: Protobuffers Are Wrong (2018)
#5Type system fans are so irritating. The author doesn't engage with the point of protocol buffers, which is that they are thin adapters between the union of things that common languages can represent with their type systems and a reasonably efficient marshaling scheme that can be compact on the wire.
Re: Protobuffers Are Wrong (2018)
#6It is a 7 year old article without specifying alternatives to an "already solved problem."
So HN, what are the best alternatives available today and why?
Re: Protobuffers Are Wrong (2018)
#7Protocol buffers suck but so does everything else. Name another serialization declaration format that both (a) defines which changes can be make backwards-compatibly, and (b) has a linter that enforces backwards compatible changes.
Just with those two criteria you’re down to, like, six formats at most, of which Protocol Buffers is the most widely used.
And I know the article says no one uses the backwards compatible stuff but that’s bizarre to me – setting up N clients and a server that use protocol buffers to communicate and then being able to add fields to the schema and then deploy the servers and clients in any order is way nicer than it is with some other formats that force you to babysit deployment order.
The reason why protos suck is because remote procedure calls suck, and protos expose that suckage instead of trying to hide it until you trip on it. I hope the people working on protos, and other alternatives, continue to improve them, but they’re not worse than not using them today.
Re: Protobuffers Are Wrong (2018)
#8Not even before the first line ends you get "They’re clearly written by amateurs". This is a rage bait, not worth the read.
The best way to get your point across is by starting with ad-hominem attacks to assert your superior intelligence.
Re: Protobuffers Are Wrong (2018)
#9The "no enums as map keys" thing enrages me constantly. Every protobuf project I've ever worked with either has stringly-typed maps all over the place because of this, or has to write its own function to parse Map into Map from the enums and then remember to call that right after deserialization, completely defeating the purpose of autogenerated types and deserializers. Why does Google put up with this? Surely it's the same inside their codebase.
Re: Protobuffers Are Wrong (2018)
#10Not even before the first line ends you get "They’re clearly written by amateurs". This is a rage bait, not worth the read.
Yep, the article opens with a Hall of Fame-grade compound fallacy: a strawman refutation of a hypothetical ad hominem that nobody has argued.
You can kinda see how this author got bounced out of several major tech firms in one year or less, each, according to their linkedin.