Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Protobuffers Are Wrong (2018)

reasonablypolymorphic.com

Post reply on HN
Print view View original

41–50 of 321 posts

Re: Protobuffers Are Wrong (2018)

#42

Post by briandw »

The crappy system that everyone ends up using is better than the perfectly designed system that's only seen in academic papers. Javascript is the poster-child of Worse is Better. Protobuffs are a PITA, but they are widely used and getting new adoption in industry. https://en.wikipedia.org/wiki/Worse_is_better

Re: Protobuffers Are Wrong (2018)

#43

Post by pshirshov »

I've created several IDL compilers addressing all issues of protobuf and others.

This particular one provides strongest backward compatibility guarantees with automatic conversion derivation where possible: https://github.com/7mind/baboon

Protobuf is dated, it's not that hard to make better things.

Re: Protobuffers Are Wrong (2018)

#44

Post by mgaunard »

gsliepen wrote: post #29
dano wrote: post #6

It 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?

Something like MessagePack or CBOR, and if you want versioning, just have a version field at the start. You don't require a schema to pack/unpack, which I personally think is a good thing.

Arrow is also becoming a good contender, with the extra benefit it is better optimized for data batches.

Re: Protobuffers Are Wrong (2018)

#45

Post by fmbb »

gsliepen wrote: post #29
dano wrote: post #6

It 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?

Something like MessagePack or CBOR, and if you want versioning, just have a version field at the start. You don't require a schema to pack/unpack, which I personally think is a good thing.

> You don't require a schema to pack/unpack

Then it hardly solves the same problem Protobuf solves.

Re: Protobuffers Are Wrong (2018)

#46

Post by omnicognate »

jeffbee wrote: post #10
ndr wrote: post #3

Not 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.

It's a terrible attitude and I agree that sort of thing shouldn't be (and generally isn't) tolerated for long in a professional environment.

That said the article is full of technical detail and voices several serious shortcomings of protobuf that I've encountered myself, along with suggestions as to how it could be done better. It's a shame it comes packaged with unwarranted personal attacks.

Re: Protobuffers Are Wrong (2018)

#47

Post by tomrod »

lalaithion wrote: post #7

Protocol 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…

> 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.

ASCII text (tongue in cheek here)

Re: Protobuffers Are Wrong (2018)

#48

Post by thinkharderdev »

rimunroe wrote: post #23
taeric wrote: post #2

I'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.

I'm just a frontend developer so most of my exposure is just as an API consumer and not someone working on the service side of things. That said: A few years ago I moved to a large company where protobufs were the standard way APIs were defined. When I first started working with the generated TypeScript code, I was confused as to why almost all fields on generated object types were marked as optional. I assumed it wa…

Yeah, as soon as you have a moderately complex type the generated code is basically useless. Honestly, ~80% of my gripes about protocol buffers could be alleviated by just allowing me to mark a message field as required.

Re: Protobuffers Are Wrong (2018)

#49

Post by jonathrg »

mkl95 wrote: post #18

If you mostly write software with Go you'll likely enjoy working with protocol buffers. If you use the Python or Ruby wrappers you'd wish you had picked another tech.

The generated types in go are horrible to work with. You can't store instances of them anywhere, or pass them by value, because they contain a bunch of state and pointers (including a [0]sync.Mutex just to explicitly prohibit copying). So you have to pass around pointers at all times, making ownership and lifetime much more complicated than it needs to be. A message definition like this

    message AppLogMessage {
        sint32 Value1 = 1;
        double Value2 = 2;
    }
becomes

    type Example struct {
        state                    protoimpl.MessageState 
        xxx_hidden_Value1        int32                  
        xxx_hidden_Value2        float64                  
        xxx_hidden_unknownFields protoimpl.UnknownFields
        sizeCache                protoimpl.SizeCache
    }
For [place of work] where we use protobuf I ended up making a plugin to generate structs that don't do any of the nonsense (essentially automating Option 1 in the article):

    type ExamplePOD struct {
        Value1 int32
        Value2 float64
    }
with converters between the two versions.
Post reply on HN