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

21–30 of 42 posts

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

#21

Post by kenshaw »

asdfasgasdgasdg wrote: post #18

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?

Yes, this has the added benefit of standardizing protocol buffer based workflows across teams / repositories. I appreciate the criticism, but we (the Brankas developers) find this syntax significantly easier to use, as well as the tooling provides a better mechanism for using other protoc generators.

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

#22

Post by kenshaw »

lowmagnet wrote: post #9
kenshaw wrote: post #2

We just pushed the first initial, public release of Gunk, a modern frontend and syntax for Protocol Buffers. Check out releases here: https://github.com/gunk/gunk/releases/tag/v0.1.0 Please note this is still extremely early / alpha stage, but we are soliciting feedback on our initial design. We hope to make this project useful to the greater developer community.

This is pretty cool. Have you all looked at the annotations to build pb in kubernetes? They use proto2 so they can use optionality, but they use a lot of annotations to write the pb like this project.

I haven't specifically looked at the Kubernetes code base, but I will -- thanks for the pointer! We plan to expand / support / better standardize the annotations in the github.com/gunk/opt package in time.

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

#23

Post by kenshaw »

joshuamorton wrote: post #11
kenshaw wrote: post #5

Earlier quoted context omitted.

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/…

In proto3 all fields are optional. As such, I don't see the need for "oneof" since you should check in business logic whether or not the field is there. By using "oneof" you are declaring two different types can be the same name. It's a philosophical argument that you're free to disagree with.

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

#24

Post by kenshaw »

tybit wrote: post #13
kenshaw wrote: post #5

Earlier quoted context omitted.

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.

I feel very strongly that type safety is of paramount importance in development, and "oneof" (and other similar constructs) in protocol design breaks fundamental ideas of type safety. It's a feature of the IDL that doesn't translate well to the actual implementing language, is not strictly necessary as the same thing can be accomplished through other designs that have an added benefit of being more explicit, both to the implementer and to the consumer.

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

#25

Post by denormalfloat »

djur wrote: post #16

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

There is a semi-consensus that Proto3 was created to be compatible as Go basic types. Making Go types from Protos, or Proto types from Go is what is being entertained as modern.

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

#26

Post by kenshaw »

99999 wrote: post #6
kenshaw wrote: post #5

Earlier quoted context omitted.

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'm curious, in your view, why should protocols not use "oneOf"?

lowmagnet more or gave a succinct summary. I've also now added other comments here, discussing my views. I don't believe it's necessary, and I would proscribe other ways to accomplish the same design. It's a philosophy of API design, not some kind of absolute stricture.

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

#27

Post by kenshaw »

erik_seaberg wrote: post #7
kenshaw wrote: post #5

Earlier quoted context omitted.

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 exists in proto3, so a tool that doesn't enforce it is likely to create messages that don't conform to the schema. The style guide also doesn't discourage it. https://developers.google.com/protocol-buffers/docs/proto3#o...

Gunk is a frontend to protoc. If one needs to use "oneof", it's still possible to just define it in a .proto file. Gunk interoperates cleanly with both .proto and .gunk files.

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

#28

Post by joshuamorton »

kenshaw wrote: post #23
joshuamorton wrote: post #11

Earlier quoted context omitted.

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/…

In proto3 all fields are optional. As such, I don't see the need for "oneof" since you should check in business logic whether or not the field is there. By using "oneof" you are declaring two different types can be the same name. It's a philosophical argument that you're free to disagree with.

In good proto2, all fields are optional, that doesn't negate the uses of one of, which provide compile time validation instead of runtime, which is the important part.

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

#29

Post by jzoch »

kenshaw wrote: post #24
tybit wrote: post #13

Earlier quoted context omitted.

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.

I feel very strongly that type safety is of paramount importance in development, and "oneof" (and other similar constructs) in protocol design breaks fundamental ideas of type safety. It's a feature of the IDL that doesn't translate well to the actual implementing language, is not strictly necessary as the same thing can be accomplished through other designs that have an added benefit of being more explicit, both to…

You believe in type safety yet refuse to let an IDL dictate a type at compile time?

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

#30

Post by kenshaw »

joshuamorton wrote: post #28
kenshaw wrote: post #23

Earlier quoted context omitted.

In proto3 all fields are optional. As such, I don't see the need for "oneof" since you should check in business logic whether or not the field is there. By using "oneof" you are declaring two different types can be the same name. It's a philosophical argument that you're free to disagree with.

In good proto2, all fields are optional, that doesn't negate the uses of one of, which provide compile time validation instead of runtime, which is the important part.

Yes, I understand how this would be done. It's a design philosophy. If you'd like Gunk to support "oneof", we're open to Pull Requests!
Post reply on HN