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

Gunk: Modern front end and syntax for Protocol Buffers

github.com

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Gunk: Modern front end and syntax for Protocol Buffers

#11

Post by joshuamorton »

kenshaw wrote: post #5
LOLOLOLO1 wrote: post #4

Earlier quoted context omitted.

Protobuf has first class enum support and also provides a thing called "oneof". Go doesn't have anything of this. So, it is clearly not the right tool for the job. Sorry guys, you are wasting your time sticking to Go constructs only.

Thanks for the input -- this actually does support enums, using a variant of Go's const: type MyEnum int const ( MYENUMVAL MyEnum = iota ) It's a philosophical argument, but one should not design a protocol using "oneof". I believe that's a relic from proto2, and I'm not aware of any modern APIs published by Google, that make use of "oneof" in anything but a legacy capacity. Gunk is not for old protobufs, it's for ne…

I was curious about this claim, so I searched for oneof in the googleapis repo[0][1]. There's a bunch of results, all in proto3, and many were committed for the first time (at least publicly) in the last 4-6 months. So I don't believe this is true.

From a safety perspective, tagged union types, which oneofs are, are incredibly useful and really should be used more often.

[0]: https://github.com/googleapis/googleapis/search?q=oneof&unsc...

[1]: I have no idea what this repo actually does, to be honest, but it appears authoritative about something, and appears to be public grpc apis Google exposes.

Re: Gunk: Modern front end and syntax for Protocol Buffers

#12

Post by whateveracct »

kenshaw wrote: post #5
LOLOLOLO1 wrote: post #4

Earlier quoted context omitted.

Protobuf has first class enum support and also provides a thing called "oneof". Go doesn't have anything of this. So, it is clearly not the right tool for the job. Sorry guys, you are wasting your time sticking to Go constructs only.

Thanks for the input -- this actually does support enums, using a variant of Go's const: type MyEnum int const ( MYENUMVAL MyEnum = iota ) It's a philosophical argument, but one should not design a protocol using "oneof". I believe that's a relic from proto2, and I'm not aware of any modern APIs published by Google, that make use of "oneof" in anything but a legacy capacity. Gunk is not for old protobufs, it's for ne…

Type systems without sums in 2019 is ignoring a lot of history and evidence, new and old.

Re: Gunk: Modern front end and syntax for Protocol Buffers

#13

Post by tybit »

kenshaw wrote: post #5
LOLOLOLO1 wrote: post #4

Earlier quoted context omitted.

Protobuf has first class enum support and also provides a thing called "oneof". Go doesn't have anything of this. So, it is clearly not the right tool for the job. Sorry guys, you are wasting your time sticking to Go constructs only.

Thanks for the input -- this actually does support enums, using a variant of Go's const: type MyEnum int const ( MYENUMVAL MyEnum = iota ) It's a philosophical argument, but one should not design a protocol using "oneof". I believe that's a relic from proto2, and I'm not aware of any modern APIs published by Google, that make use of "oneof" in anything but a legacy capacity. Gunk is not for old protobufs, it's for ne…

I just can’t get my head around this reasoning, it’s just as valid to ask for/return a “foo OR bar” as it is to ask for a “foo AND bar”. Any protocol that rejects that pushes that complexity elsewhere, somewhere less explicit.

Re: Gunk: Modern front end and syntax for Protocol Buffers

#14

Post by helpme3 »

kenshaw wrote: post #5
LOLOLOLO1 wrote: post #4

Earlier quoted context omitted.

Protobuf has first class enum support and also provides a thing called "oneof". Go doesn't have anything of this. So, it is clearly not the right tool for the job. Sorry guys, you are wasting your time sticking to Go constructs only.

Thanks for the input -- this actually does support enums, using a variant of Go's const: type MyEnum int const ( MYENUMVAL MyEnum = iota ) It's a philosophical argument, but one should not design a protocol using "oneof". I believe that's a relic from proto2, and I'm not aware of any modern APIs published by Google, that make use of "oneof" in anything but a legacy capacity. Gunk is not for old protobufs, it's for ne…

That isn't an enum because it's valid to do SOME_NON_ENUM_VALUE = MyEnum(10) in Go.

Re: Gunk: Modern front end and syntax for Protocol Buffers

#15

Post by atombender »

kenshaw wrote: post #5
LOLOLOLO1 wrote: post #4

Earlier quoted context omitted.

Protobuf has first class enum support and also provides a thing called "oneof". Go doesn't have anything of this. So, it is clearly not the right tool for the job. Sorry guys, you are wasting your time sticking to Go constructs only.

Thanks for the input -- this actually does support enums, using a variant of Go's const: type MyEnum int const ( MYENUMVAL MyEnum = iota ) It's a philosophical argument, but one should not design a protocol using "oneof". I believe that's a relic from proto2, and I'm not aware of any modern APIs published by Google, that make use of "oneof" in anything but a legacy capacity. Gunk is not for old protobufs, it's for ne…

"Oneof" is certainly not a relic of proto2.

Re: Gunk: Modern front end and syntax for Protocol Buffers

#16

Post by djur »

I'm not seeing what makes this "modern". proto3 is only a few years old and nothing about it strikes me as unusually archaic. Protobuf in general isn't that much older than Go. I can see why Go-compatible syntax would be attractive to Go developers, so maybe that should be in the description rather than "modern"?

Re: Gunk: Modern front end and syntax for Protocol Buffers

#17

Post by stubish »

lowmagnet wrote: post #8
99999 wrote: post #6

Earlier quoted context omitted.

I'm curious, in your view, why should protocols not use "oneOf"?

Not GP commenter, but a lot of the decisions to remove explicit optionality and requiredness from protocol buffer is that it made pb too complicated to change when you wanted to make a field required or optional, so they punted with 3 and said "do this in service logic" I think the feeling is that this is the realm of business logic, and a protocol should be simple and fast and not concern itself with the rules part…

I can't follow that argument, as it seems to apply just as much to wanting to change the type of a field, the name of a field or just making changes in general. Maybe I deal with relational databases too much, but I really miss being able to declare fields required and provide default values, because now instead I have to document, trust others will read the documentation, and provide explicit error handling for when constraints that used to be validated client side or server side by protobuf. I also miss not having a NULL value, but protobuf never had that and almost certainly due to dealing with too many relational databases ;)

If I lose oneof too, I might as well be using JSON.

Re: Gunk: Modern front end and syntax for Protocol Buffers

#18

Post by asdfasgasdgasdg »

I'd be interested to see a "why?" section in your docs. In general I think making new "skins" for the same underlying tech is not a good thing. It fragments the ecosystem without any real business purpose. Is there some problem this addresses that is not already solved equally well by proto2 or proto3, besides that it doesn't look like a particular programming language?

Re: Gunk: Modern front end and syntax for Protocol Buffers

#20

Post by kenshaw »

grogenaut wrote: post #19

Not sure why I’d want to define a language independent interchange format in a language specific way and remove all of the tooling help at the same time. Why is this better? A why section/motivations would help greatly.

There is an explanation in the README file, but I'll explain:

It helps to standardize workflows across a number of different source repositories (all Go based), where a number of different developers had come up with different ad-hoc ways of generating code against protobuf definitions. Since the syntax is Go-derived, it reduces cognitive load for developers when specifying protocol buffer definitions. We understand that it may not be for everyone, but it works for our team.

Post reply on HN