
Gunk: Modern front end and syntax for Protocol Buffers - kenshaw
https://github.com/gunk/gunk
======
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"?

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

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

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

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

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

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

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

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

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

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

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

~~~
lowmagnet
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)

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

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

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

------
joneholland
I don’t understand the purpose. The existing proto syntax is both easy to
learn and language agnostic.

I’ve watched new devs pick it up in a matter of minutes.

------
SrslyJosh
"Modern"?

