Arguing against using protobuffers

#1

Post by haskellandchill » Wed, Oct 10, 2018, 8:24 PM UTC

Arguing against using protobuffers
reasonablypolymorphic.com

Re: Arguing against using protobuffers

#2

Post by sonnyblarney » Wed, Oct 10, 2018, 8:47 PM UTC

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

Re: Arguing against using protobuffers

#3

Post by k__ » Wed, Oct 10, 2018, 9:41 PM UTC

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 know a few companies who use flatbuffers instead.

Re: Arguing against using protobuffers

#4

Post by twic » Wed, Oct 10, 2018, 9:44 PM UTC

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

Re: Arguing against using protobuffers

#5

Post by amluto » Wed, Oct 10, 2018, 9:48 PM UTC

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

Depending on your goals, Cap’n Proto is excellent.

Re: Arguing against using protobuffers

#6

Post by CobrastanJorji » Wed, Oct 10, 2018, 9:48 PM UTC

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.

Re: Arguing against using protobuffers

#7

Post by jeremyjh » Wed, Oct 10, 2018, 9:50 PM UTC

amluto wrote: post #5

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

Depending on your goals, Cap’n Proto is excellent.

Which of the problems listed in the article are solved by it?

Re: Arguing against using protobuffers

#8

Post by justicezyx » Wed, Oct 10, 2018, 9:51 PM UTC

Wow, some minor complaints on language formality issues, then discredit the thing as a whole.

But in the end, the author probably does not understand PB solves the inter-language data sharing problem, which makes all its complain secondary and inconsequential.

It's like complaining a car that drives fast and has great gas efficiency of cannot talk. (Well in 2018, it might be less of a stretch to demand a car that can talk)

Re: Arguing against using protobuffers

#9

Post by tlarkworthy » Wed, Oct 10, 2018, 9:52 PM UTC

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

JSON or graphql. Personally I think the typing, API compatibility and extensive language support make protobuffers currently the winner though, despite the warts

Re: Arguing against using protobuffers

#10

Post by rb808 » Wed, Oct 10, 2018, 9:52 PM UTC

Versioning was the biggest disappointment for me. I just want a middleware layer that can handle clients of different versions reliably. Surely everyone has the same problem.