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

Arguing against using protobuffers

reasonablypolymorphic.com

Post reply on HN
Print view View original

11–20 of 307 posts

Re: Arguing against using protobuffers

#11

Post by _dmurph »

Mostly lost me at "Make all fields in a message required. This makes messages product types."

Your constraints on protocols can change over time and context, changing something that is required to something that is optional can cause crashes in prod. Unless somehow the 'optional' design has a way to handle that? You also will have to do custom validation anyways, as your storage format will never be able to enforce all constraints you care about.

Also, it would seem like the 'debate' of optional vs required is harmful was resolved, as proto3 makes everything optional.

Re: Arguing against using protobuffers

#12

Post by danharaj »

_dmurph wrote: post #11

Mostly lost me at "Make all fields in a message required. This makes messages product types." Your constraints on protocols can change over time and context, changing something that is required to something that is optional can cause crashes in prod. Unless somehow the 'optional' design has a way to handle that? You also will have to do custom validation anyways, as your storage format will never be able to enforce a…

Like, 5 lines later:

> For example, we can rebuild optional fields:

Re: Arguing against using protobuffers

#14

Post by vl »

_dmurph wrote: post #11

Mostly lost me at "Make all fields in a message required. This makes messages product types." Your constraints on protocols can change over time and context, changing something that is required to something that is optional can cause crashes in prod. Unless somehow the 'optional' design has a way to handle that? You also will have to do custom validation anyways, as your storage format will never be able to enforce a…

If you would continue reading, there is an explanation of how optional would work almost immediately after this quote.

Re: Arguing against using protobuffers

#15

Post by amelius »

twic wrote: post #4

> Despite map fields being able to be parameterized, no user-defined types can be. This means you'll be stuck hand-rolling your own specializations of common data structures. What a pain! Well, at least Google won't make that mistake again!

You can always write a code-generator to ease the pain.

Re: Arguing against using protobuffers

#16

Post by weberc2 »

CobrastanJorji wrote: post #6
sonnyblarney wrote: post #2

Good points, but can someone articulate what the best alternative to protobuffers would be in 2018, you know with 'hindsight' etc.?

I've heard good things about https://capnproto.org/ but the author of this piece may strongly disagree, since I think their objections are rather more fundamental, and also because Cap'n Proto went with banning the concept of "required" fields. I'd also be interested in what alternatives the author might suggest.

Capnproto is built by the guy who originally built protobufs, and he cites capnproto as being better because he was able to learn from his mistakes. Makes me optimistic.

Re: Arguing against using protobuffers

#17

Post by nemothekid »

>Fields with scalar types are always present. Even if you don't set them. Did I mention that (at least in proto3) all protobuffers can be zero-initialized with absolutely no data in them?

I don't this complaint. You have to initialize data with something. proto2 had to "solve" this problem in C/C++/Go by making everything a pointer. How is dealing with null the "sane" case against zero-initialization?

Re: Arguing against using protobuffers

#18

Post by [deleted] »

_dmurph wrote: post #11

Mostly lost me at "Make all fields in a message required. This makes messages product types." Your constraints on protocols can change over time and context, changing something that is required to something that is optional can cause crashes in prod. Unless somehow the 'optional' design has a way to handle that? You also will have to do custom validation anyways, as your storage format will never be able to enforce a…

[deleted]

Re: Arguing against using protobuffers

#19

Post by k__ »

amelius wrote: post #15
twic wrote: post #4

> Despite map fields being able to be parameterized, no user-defined types can be. This means you'll be stuck hand-rolling your own specializations of common data structures. What a pain! Well, at least Google won't make that mistake again!

You can always write a code-generator to ease the pain.

That's what I hear from Go devs all the time, doesn't sound convicing to me.

Re: Arguing against using protobuffers

#20

Post by _dmurph »

danharaj wrote: post #12
_dmurph wrote: post #11

Mostly lost me at "Make all fields in a message required. This makes messages product types." Your constraints on protocols can change over time and context, changing something that is required to something that is optional can cause crashes in prod. Unless somehow the 'optional' design has a way to handle that? You also will have to do custom validation anyways, as your storage format will never be able to enforce a…

Like, 5 lines later: > For example, we can rebuild optional fields:

How is this different than having both required and optional.
Post reply on HN