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

A new Go API for Protocol Buffers

blog.golang.org

Post reply on HN
Print view View original

81–90 of 100 posts

Re: A new Go API for Protocol Buffers

#81

Post by atilaneves »

uluyol wrote: post #50
AaronFriel wrote: post #35

Not to be too Rust evangelist here, but why the emphasis on reflection instead of further support for generics? On the Rust side, macros can[1] transform .proto files into data structure definitions at compile time, and instances of the structs passed around have the benefit of strong typing, code completion in editors, lints and tests can easily validate properties of protobuf objects and so on. And all without addi…

Compile time generic programming is not a replacement for runtime reflection. A great example of this is if you want to use dynamically generated protocol buffers. A great usecase for this is if you want to store each row in a database as a proto message. Instantiate a descriptor based on the table schema and go.

> Compile time generic programming is not a replacement for runtime reflection.

Yes, it is, especially since the former can be used to implement the latter.

Re: A new Go API for Protocol Buffers

#82

Post by jackielii »

dgellow wrote: post #4

> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. That's such a weird choice, and will be quite confusing. Now every time you see protobuf being imported, you have to be sure to pay extra attention to the domain used, and correctly remember w…

I believe this is discussed and decided quite early on: https://docs.google.com/document/d/19kfhro7-CnBdFqFk7l4_Hmwa...

>According to the Import Compatiability Rule for versioned Go, this implies that the new proto package must have a new import path. Since "github.com/protobuf/proto/v2" will incur great confusion with the proto2 syntax, we may take this time to use an import path like "google.golang.org/proto" (similar to how gRPC lives at "google.golang.org/grpc").

Re: A new Go API for Protocol Buffers

#83

Post by DelightOne »

atombender wrote: post #32

Hopefully this is good news. The old Protobuf package had ossified, with lots of ergonomic issues that the maintainers seemed uninterested in addressing. One perennial annoyance is how awkwardly some Protobuf stuff ends up being represented in Go. For example, "oneof" types: message Event { oneof payload { Create create = 1; Delete delete = 2; } } message Create { string id = 1; } message Delete { string version = 1;…

Do you know whether they fixed oneof with APIv2?

Re: A new Go API for Protocol Buffers

#84

Post by dgellow »

icholy wrote: post #10
dgellow wrote: post #4

> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. That's such a weird choice, and will be quite confusing. Now every time you see protobuf being imported, you have to be sure to pay extra attention to the domain used, and correctly remember w…

> If only go modules established a clear way to differentiate API versions using the import path! It did, they just chose not to follow it :/ I wonder what rsc thinks about this decisions

I know, that sentence was meant to be ironic :)

Re: A new Go API for Protocol Buffers

#85

Post by breakingcups »

guessmyname wrote: post #41

> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. > We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. > (Why start at version v1.20.0? To provide clarity. We do not anticipate APIv1 to ever reach v1.20.0, so the version number alone should be enough to unambiguously differentiate between API…

I loved Go's simplicity when it came out.

However, it has become clear to me that it was a little too simple to handle all the new requirements and additions that came after v1.

That's how you get weird comments-as-code (// +build linux,386 darwin,!cgo), strings-as-attributes (tags), tacked-on modules versioning / vendoring, non-typed generics( interface{} everywhere), somewhat-typed generics (go generate), etc.

Go was not quite ready to handle all these directions people wanted the language to stretch to and as a result it's now already full of annoying warts.

I'll still pick Go if I need a simple service with amazing performance. Funnily enough though, I have no need for any of the (non-performance) additions that came after 1.6.

Re: A new Go API for Protocol Buffers

#86

Post by sethammons »

mastrsushi wrote: post #67

Hackernews, where the highlight of mentioning common libraries is the fact that they're done so in Go and Rust.

I find that to be a feature. If I open the article and/or comments and find out this was about a library for Ruby or Java then I wasted my time because I don't use those. Likewise, a non-Go or non-Rust dev can ignore Go and/or Rust tagged library articles.

Re: A new Go API for Protocol Buffers

#87

Post by pdexter »

jackielii wrote: post #82
dgellow wrote: post #4

> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. That's such a weird choice, and will be quite confusing. Now every time you see protobuf being imported, you have to be sure to pay extra attention to the domain used, and correctly remember w…

I believe this is discussed and decided quite early on: https://docs.google.com/document/d/19kfhro7-CnBdFqFk7l4_Hmwa... >According to the Import Compatiability Rule for versioned Go, this implies that the new proto package must have a new import path. Since "github.com/protobuf/proto/v2" will incur great confusion with the proto2 syntax, we may take this time to use an import path like "google.golang.org/proto" (simi…

Random question, but how did they get the source code highlighting in that doc?

Re: A new Go API for Protocol Buffers

#88

Post by konart »

pdexter wrote: post #87
jackielii wrote: post #82

Earlier quoted context omitted.

I believe this is discussed and decided quite early on: https://docs.google.com/document/d/19kfhro7-CnBdFqFk7l4_Hmwa... >According to the Import Compatiability Rule for versioned Go, this implies that the new proto package must have a new import path. Since "github.com/protobuf/proto/v2" will incur great confusion with the proto2 syntax, we may take this time to use an import path like "google.golang.org/proto" (simi…

Random question, but how did they get the source code highlighting in that doc?

Code Blocks addong from G Suit Market (new doco -> addons -> Install -> Code Blocks)

Re: A new Go API for Protocol Buffers

#90

Post by jacques_chester »

stubish wrote: post #60
AaronFriel wrote: post #35

Not to be too Rust evangelist here, but why the emphasis on reflection instead of further support for generics? On the Rust side, macros can[1] transform .proto files into data structure definitions at compile time, and instances of the structs passed around have the benefit of strong typing, code completion in editors, lints and tests can easily validate properties of protobuf objects and so on. And all without addi…

A Go API for protobufs can't support generics because Go doesn't support generics, yet. I guess the protobufs team didn't want to wait until Go v2, probably a good call given Go v1.x is going to be around for years. In Go, a code generator converts the .proto files into Go code, which give the same benefits you see with the Rust macros. Its arguable if a code generation step is better or worse than macros. The reflec…

> Its arguable if a code generation step is better or worse than macros.

I don't need elaborate, brittle shell scripts to correctly update my compiler macros in order of dependency. I only need the compiler.

Post reply on HN