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

Protocol Buffers v3.0.0 released

github.com

Post reply on HN
Print view View original

11–20 of 131 posts

Re: Protocol Buffers v3.0.0 released

#11

Post by IshKebab »

forrestthewoods wrote: post #7

Google also has flatbuffers. I wonder if flatbuffers is being used by enough developers to justify significant development? https://github.com/google/flatbuffers

I think it's more that GRPC (Google's RPC-over-HTTP2 protocol) directly supports Protobuf, and not Flatbuffers. All of Google's Cloud APIs use Protobuf (for example the [Speech API](https://cloud.google.com/speech/reference/rpc/) ).

I have to say, GRPC is pretty great. It's statically typed, supports loads of languages, the interfaces are simple to define (basically Protobuf), and it supports streaming requests! Most RPC systems omit that, or only have message streams (e.g. MQTT). Good RPC systems need both.

The only downside I find is that it is rather complicated (in design; not use).

Re: Protocol Buffers v3.0.0 released

#15

Post by dkopi »

manish_gill wrote: post #12

If someone better informed than me can please explain - where and why would something like Protocol Buffers be useful?

> Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.

From https://developers.google.com/protocol-buffers/

Re: Protocol Buffers v3.0.0 released

#16

Post by zellyn »

- removing optional values is actually quite nice. In practice, I end up checking for "missing or empty string" anyway.

- the "well-known types" boxed primitive types essentially add optional values back in. And depending on your language bindings, may look the same.

- extensions are still allowed in proto3 syntax files, but only for options - since the descriptor is still proto2. It seems odd to build a proto3 that couldn't represent descriptors.

- I still don't understand the removal of unknown fields. Reserialization of unknown fields was always the first defining characteristic of protobufs I described to people. I actually read many of the design/discussion docs internally when I worked at Google, and I still couldn't figure this one out. Although it's certainly simpler…

- Protobufs are the "lifeblood" (Rob Pike's words) of Google: the protobuf team is working to get rid of significant Lovecraftian internal cruft, after which their ability to incorporate open source contributions should improve dramatically.

Re: Protocol Buffers v3.0.0 released

#18

Post by manish_gill »

dkopi wrote: post #15
manish_gill wrote: post #12

If someone better informed than me can please explain - where and why would something like Protocol Buffers be useful?

> Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. From https://developers.google…

Yes, I read this. It tells me what Protocol Buffers are. Faster, Smaller XML like data structures for serialisation. What are the most common use cases though? And do people only use them for performance reasons?

Re: Protocol Buffers v3.0.0 released

#20

Post by phamilton »

manish_gill wrote: post #12

If someone better informed than me can please explain - where and why would something like Protocol Buffers be useful?

For me there are three main advantages: schema, performance and code generation.

Having a strict schema makes it a lot easier to maintain applications in a distributed system. Parsing protobuf is much faster than something like JSON. The multitude of code generators for protobuf make it really simple and easy to use multiple languages on the same data structures.

Post reply on HN