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

A new Go API for Protocol Buffers

blog.golang.org

Post reply on HN
Print view View original

91–100 of 100 posts

Re: A new Go API for Protocol Buffers

#91

Post by twblalock »

stubish wrote: post #60
AaronFriel wrote: post #35

Not to be too Rust evangelist here, but why the emphasis on reflection instead of further support for generics? On the Rust side, macros can[1] transform .proto files into data structure definitions at compile time, and instances of the structs passed around have the benefit of strong typing, code completion in editors, lints and tests can easily validate properties of protobuf objects and so on. And all without addi…

A Go API for protobufs can't support generics because Go doesn't support generics, yet. I guess the protobufs team didn't want to wait until Go v2, probably a good call given Go v1.x is going to be around for years. In Go, a code generator converts the .proto files into Go code, which give the same benefits you see with the Rust macros. Its arguable if a code generation step is better or worse than macros. The reflec…

> Its arguable if a code generation step is better or worse than macros.

I'd rather just have generics.

Code generation for protos is nice for several reasons, but using it as an alternative to generics is not nice at all. I work on a number of projects with generics in internal classes that are not exposed as an API, and using code generation just to get those to work seems like a very big hammer for a small nail.

Re: A new Go API for Protocol Buffers

#92

Post by atombender »

DelightOne wrote: post #83
atombender wrote: post #32

Hopefully this is good news. The old Protobuf package had ossified, with lots of ergonomic issues that the maintainers seemed uninterested in addressing. One perennial annoyance is how awkwardly some Protobuf stuff ends up being represented in Go. For example, "oneof" types: message Event { oneof payload { Create create = 1; Delete delete = 2; } } message Create { string id = 1; } message Delete { string version = 1;…

Do you know whether they fixed oneof with APIv2?

No, I don't think so! My point was that I hope this change will renew development a bit and perhaps allow more breaking changes.

Re: A new Go API for Protocol Buffers

#93

Post by uluyol »

jsnell wrote: post #75
stubish wrote: post #60

Earlier quoted context omitted.

A Go API for protobufs can't support generics because Go doesn't support generics, yet. I guess the protobufs team didn't want to wait until Go v2, probably a good call given Go v1.x is going to be around for years. In Go, a code generator converts the .proto files into Go code, which give the same benefits you see with the Rust macros. Its arguable if a code generation step is better or worse than macros. The reflec…

If you don't have the proto definition, there's nothing you can do except pass the object through unmodified. And you should not need a reflection API for that (unless the v1 API was totally messed up in other ways). Without the definition (and knowing the type!) there won't be anything around to tell the reflection API what the names, types and annotations are. All you would have is field numbers mapped to opaque bl…

You can pass around a type descriptor (itself a proto message) along with the opaque message.

Re: A new Go API for Protocol Buffers

#94

Post by DelightOne »

atombender wrote: post #92
DelightOne wrote: post #83

Earlier quoted context omitted.

Do you know whether they fixed oneof with APIv2?

No, I don't think so! My point was that I hope this change will renew development a bit and perhaps allow more breaking changes.

Hmm! Hehe I had hope. I can't imagine them doing breaking changes after a fresh api release though sadly.

Re: A new Go API for Protocol Buffers

#95

Post by EdSchouten »

atombender wrote: post #32

Hopefully this is good news. The old Protobuf package had ossified, with lots of ergonomic issues that the maintainers seemed uninterested in addressing. One perennial annoyance is how awkwardly some Protobuf stuff ends up being represented in Go. For example, "oneof" types: message Event { oneof payload { Create create = 1; Delete delete = 2; } } message Create { string id = 1; } message Delete { string version = 1;…

You need the intermediate struct, because there may be multiple entries in the oneof that share the same type. Not having the intermediate struct would make it impossible to distinguish them.

Re: A new Go API for Protocol Buffers

#96

Post by atombender »

EdSchouten wrote: post #95
atombender wrote: post #32

Hopefully this is good news. The old Protobuf package had ossified, with lots of ergonomic issues that the maintainers seemed uninterested in addressing. One perennial annoyance is how awkwardly some Protobuf stuff ends up being represented in Go. For example, "oneof" types: message Event { oneof payload { Create create = 1; Delete delete = 2; } } message Create { string id = 1; } message Delete { string version = 1;…

You need the intermediate struct, because there may be multiple entries in the oneof that share the same type. Not having the intermediate struct would make it impossible to distinguish them.

That seems like a rare edge case. Simple solution: Only use an intermediate struct if actually needed.

Re: A new Go API for Protocol Buffers

#98

Post by AaronFriel »

kccqzy wrote: post #58
AaronFriel wrote: post #35

Not to be too Rust evangelist here, but why the emphasis on reflection instead of further support for generics? On the Rust side, macros can[1] transform .proto files into data structure definitions at compile time, and instances of the structs passed around have the benefit of strong typing, code completion in editors, lints and tests can easily validate properties of protobuf objects and so on. And all without addi…

That's not very scalable. Putting more logic in a macro means the compiler needs to reprocess it each time the file is touched, even when the part that's changed is not the protos. A separate code gen step means the proto compiler doesn't need to be invoked as often, and the generated files don't need to be recompiled either. > Will anything downstream match the ".proto" of an object that's missing a bunch of require…

That doesn't sound right, I don't think there's any reason a proc macro couldn't cache the .proto file's generated code and use the cache between runs.

Re: A new Go API for Protocol Buffers

#99

Post by EdSchouten »

atombender wrote: post #96
EdSchouten wrote: post #95

Earlier quoted context omitted.

You need the intermediate struct, because there may be multiple entries in the oneof that share the same type. Not having the intermediate struct would make it impossible to distinguish them.

That seems like a rare edge case. Simple solution: Only use an intermediate struct if actually needed.

That has the downside of causing build breakage if seemingly unrelated fields are added/removed from Protobuf messages.

Re: A new Go API for Protocol Buffers

#100

Post by yencabulator »

zerr wrote: post #73
neild wrote: post #3

Earlier quoted context omitted.

Nah, we just really wanted to stop using an import path tied to a specific hosting provider. Once we decided to change to an entirely different path, we waffled a lot over whether to tag it v1 or v2. There were arguments for and against either, so we eventually picked one and went with it.

> we just really wanted to stop using an import path tied to a specific hosting provider Are there any plans to fix this for the whole language, for others as well? i.e. use namespaces, module names in the source but move the actual github.com, google.com or geocities.com URLs outside.

The support has been there for a long time. `go help importpath`
Post reply on HN