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

121–130 of 131 posts

Re: Protocol Buffers v3.0.0 released

#121

Post by colanderman »

cbsmith wrote: post #118
colanderman wrote: post #102

Earlier quoted context omitted.

I've never looked at proto3, but proto2 has at least the following issues: * No clue about namespacing. If you pick the wrong name for something, you can have name clashes within a protobuf, across uninterpreted option classes, with protobuf source code, with your own source code; and it's different if you're in Python or C. Nowhere are naming restrictions defined. * The API is maddening and inconsistent, especially…

The short answer is the Python implementation wasn't exactly great.

Reflection in the C++ version is as bad or worse given that you can't mess around with it in a REPL to figure out how it really works. And the C++ version has most of the namespacing issues (e.g. any field starting with "set_" has potential to clash with another field).

Both implementations are equally bad, despite that they seem to have been written by two separate teams that didn't communicate with each other.

Re: Protocol Buffers v3.0.0 released

#122

Post by [deleted] »

colanderman wrote: post #102
grosbisou wrote: post #3

Earlier quoted context omitted.

Could you expand on the problems you encountered?

I've never looked at proto3, but proto2 has at least the following issues: * No clue about namespacing. If you pick the wrong name for something, you can have name clashes within a protobuf, across uninterpreted option classes, with protobuf source code, with your own source code; and it's different if you're in Python or C. Nowhere are naming restrictions defined. * The API is maddening and inconsistent, especially…

[deleted]

Re: Protocol Buffers v3.0.0 released

#123

Post by Dylan16807 »

jhspaybar wrote: post #110
amluto wrote: post #45

They added a feature that impressively fails to interoperate with the rest of the world. > Added well-known type protos (any.proto, empty.proto, timestamp.proto, duration.proto, etc.). Users can import and use these protos just like regular proto files. Additional runtime support are available for each language. From timestamp.proto: // A Timestamp represents a point in time independent of any time zone // or calenda…

It saddens me that this is the top comment. It's complete and total FUD unrelated in any way to what Proto is, and to boot, it's an optional type, provided if you want it, but otherwise not forced to be used in any way! Scroll down the page for much more worthwhile discussions of Proto.

A tangent, perhaps. But it's not FUD.

Re: Protocol Buffers v3.0.0 released

#124

Post by gonyea »

Shocking! Google's started supporting more languages than just the ones they care about. I really hope this signals the death of their disdain culture.

Being a worthwhile Cloud provider means hiring experts in all sorts of languages and supporting their efforts.

Imagine a world where Google didnt just "support node" (YEARS late), but actually turned their v8 expertise into a Cloud product.

But that'd involve convincing Java-devs-turned-VPs to care about JavaScript, and EVERYONE knows that JavaScript is a terrible language.

Re: Protocol Buffers v3.0.0 released

#125

Post by jokoon »

rdtsc wrote: post #64

How does this compare or in general why would you pick this vs newer formats like Cap'n'proto or FlatBuffers? From FlatBuffers overview I see this comparison: --- Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary difference being that FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data, often coupled with per-object memory allocatio…

I don't know, but I tried using protocol buffer once for mapbox vector files, the resulting C++ header was huge. It had templates and all sort of things, something like more than 1000 lines.

Re: Protocol Buffers v3.0.0 released

#126

Post by NikhilVerma »

vtalwar wrote: post #62
NikhilVerma wrote: post #34

Earlier quoted context omitted.

At Badoo we use them to have a unified API for all of our platforms (Web, Mobile Web, Android, iOS, Windows Phone etc). This would not have been possible without something like ProtoBuf.

Nikhil, would love to know more about your architecture.

We have a presentation about that here: https://techblog.badoo.com/blog/2014/09/13/building-a-mainta...

Re: Protocol Buffers v3.0.0 released

#127

Post by skybrian »

ambrice wrote: post #108
skybrian wrote: post #92

Earlier quoted context omitted.

Right, but nobody's going to set that for every single protobuf field.

You're right. The only people that would use it are people that a) care enough about optimization to switch out shorter tag names and b) don't care enough about optimization to switch to binary format. Probably not many..

Except everyone who is doing RPC in a browser. Not sure why that is, but binary formats aren't popular. We still care about performance.

Re: Protocol Buffers v3.0.0 released

#128

Post by cbsmith »

colanderman wrote: post #121
cbsmith wrote: post #118

Earlier quoted context omitted.

The short answer is the Python implementation wasn't exactly great.

Reflection in the C++ version is as bad or worse given that you can't mess around with it in a REPL to figure out how it really works. And the C++ version has most of the namespacing issues (e.g. any field starting with "set_" has potential to clash with another field). Both implementations are equally bad, despite that they seem to have been written by two separate teams that didn't communicate with each other.

Honestly, I never had much trouble with the C++ one.

Re: Protocol Buffers v3.0.0 released

#129

Post by euyyn »

andrewmcwatters wrote: post #107
euyyn wrote: post #93

Earlier quoted context omitted.

In the vast majority of cases, you want your team to spend their time doing something other than reinventing protos, debugging the in-house implementation, maintaining the library, etc. It's not clear to me anyway how doing it yourself would help keeping your codebase small vs using protos. In terms of code to maintain, doing it yourself is a net loss. In terms of binary size and method count, the proto libraries for…

Those are all reasons why I wanted to use protobufs to begin with. It sounded like it solved many issues for us. But I'm thinking about scripting environments, where the data types used in protobufs don't exist in the host language. Simple things like this. I think in the implementations I've seen, they're just coerced or ignored. That's fine, imo. But in terms of small codebases: a simple TLV protocol, where only li…

I'm a bit confused: When you talk of size, are you talking of the compiled binary size of the runtime + generated code, or are you talking of lines of code?

If you're talking of binary size, I'm surprised that it'd be a problem given that you're using a scripting environment. Maybe you'd be willing to share more details?

If you're talking of lines of code, using someone else's library seems to me to always be better.

Re: Protocol Buffers v3.0.0 released

#130

Post by teacup50 »

cbsmith wrote: post #119
teacup50 wrote: post #116

Earlier quoted context omitted.

> A canonical example is that you add a required field ... Yeah. Don't do that without versioning your protocol. It's even less difficult to handle than maintaining API/ABI compatibility in a library. > So practically speaking, you can never add required fields to any message where you can't guarantee binary version syncing amongst all instances of the message-dependent services. Sure you can. If you version things a…

> Yeah. Don't do that without versioning your protocol. It's even less difficult to handle than maintaining API/ABI compatibility in a library. Actually, the whole point of that was so you don't have to version your protocol. Protocol versioning actually tends to make code maintenance a pain in the posterior, and working through old data really annoying. Instead, you do optional fields. If you don't want that, go ahe…

> If you don't want that, go ahead and just write raw bytes and don't bother with the serialization layer.

Or just keep using protobuf2, 'cause it's been working great for us for ~6 years.

> But you don't have to do either. It seems like you aren't familiar with the use of protocol buffers.

I've written my own protobuf compiler. I'm familiar.

> You just define optional fields with a reasonable default, and magically all the old protobufs get that default value.

That only works up until there's no "reasonable default".

Post reply on HN