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

31–40 of 42 posts

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

#31

Post by xyzzy_plugh »

stubish wrote: post #17
lowmagnet wrote: post #8

Earlier quoted context omitted.

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…

Your points are valid, but ultimately an API is defined by its semantics in addition to data types. For anything beyond extremely primative RPC, you have to read the docs anyways.

Moving to proto3 means putting all your validation in one place, your serialization primitives in one place, and your docs in one place, instead of smattering them all over. It's a lot less error prone and way more maintenance friendly.

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

#32

Post by inciampati »

denormalfloat wrote: post #25
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.

The compatibility is not just with Go types, but any C structure compatible types in any language.

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

#34

Post by joshuamorton »

xyzzy_plugh wrote: post #31
stubish wrote: post #17

Earlier quoted context omitted.

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…

Your points are valid, but ultimately an API is defined by its semantics in addition to data types. For anything beyond extremely primative RPC, you have to read the docs anyways. Moving to proto3 means putting all your validation in one place, your serialization primitives in one place, and your docs in one place, instead of smattering them all over. It's a lot less error prone and way more maintenance friendly.

Why is `// required, the server will respond with a failure if this argument isn't provided` in the .proto file enough documentation? That's usually what I go to.

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

#35

Post by [deleted] »

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.

[deleted]

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

#37

Post by WaltPurvis »

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.

It would be good to explain (perhaps in a blog post) why this is useful. It's not obvious to me.

Neither the syntax nor build process for protocol buffers has ever seemed particularly difficult.

You mentioned something about cognitive load, but even as a Go developer this looks like it would add to my cognitive load. I have to learn/remember this new syntax and learn/remember the (imperfect) ways in which it maps to protocol buffers, etc.

I could really use some concrete examples of the ways this is better.

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

#38

Post by grogenaut »

kenshaw wrote: post #20
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…

Why not just make a simple go tool that just covers that issue and still uses proto thus getting the tooling and expressiveness instead.

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

#39

Post by djur »

denormalfloat wrote: post #25
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.

Proto3 has features (discussed elsewhere in these comments, like oneOf) that aren't present in Go's type system. I'm not clear on why constraining it so it's more narrowly compatible with a particular implementing language is more modern.

It would be useful to see an example of the workflow of using this tool compared with the equivalent workflow while using protoc. That would be a selling point, while "modern" is just a sticking point.

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

#40

Post by xiphias2 »

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…

Let me guess: you are talking about types and type safety without learning type theory and type algebra. You are just throwing out 1 of the two basic building blocks of type algebra and sticking to your point even though everybody tells you how important it is. Anyways it's ok if you want to be Go specific, this is totally fine.
Post reply on HN