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

1–10 of 42 posts

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

#2

Post by kenshaw »

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.

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

#4

Post by LOLOLOLO1 »

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.

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.

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

#5

Post by kenshaw »

LOLOLOLO1 wrote: post #4
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.

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 new development. It works with and integrates cleanly with existing protobuf definitions.

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

#6

Post by 99999 »

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

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

#7

Post by erik_seaberg »

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 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...

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

#8

Post by lowmagnet »

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

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 of the underlying service.

Oneof seems to fall under the same concept, where it says "one and only one field from this list" when they can just as easily do that in service or client logic (three fields, documentation and a server response custom written as to the WHY of oneof relationship)

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

#9

Post by lowmagnet »

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.

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

#10

Post by chubot »

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 was NEW in proto3 as far as I know, not a relic of proto2. I've ONLY used proto2 and I've never used oneof.
Post reply on HN