Does someone know if this new version uses fast generated code for (de)serialization? The previous version was pretty slow (because based on reflection I think) so many people used https://github.com/gogo/protobuf for good performance.
A new Go API for Protocol Buffers
71–80 of 100 posts
Re: A new Go API for Protocol Buffers
#72Earlier quoted context omitted.
Indeed, tying the name of a package to a hosting provider is a bad idea! That's why we changed to an import path which isn't tied to one. google.golang.org/protobuf is not tied to any particular provider, and we can redirect it wherever we want. See "go help importpath" for details on how this works.
> - Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does. > google.golang.org/protobuf is not tied to any particular provider, and we can redirect it wherever we want. I agree, this is confusing. Why doesn't google.golang.org/protobuf@v1 return what's at github.com/golang/protobuf, then, if only to provide a tidy answer for those who wonder what v1 looked like?
Because the Go package name is github.com/golang/protobuf. Serving it from a different address is already a breaking change.
Re: A new Go API for Protocol Buffers
#73Interesting that even Google decided to do complex versioning gymnastics and introduce a new namespace in order to avoid how `go mod` adds the version as a path component.
Nah, we just really wanted to stop using an import path tied to a specific hosting provider. Once we decided to change to an entirely different path, we waffled a lot over whether to tag it v1 or v2. There were arguments for and against either, so we eventually picked one and went with it.
> we just really wanted to stop using an import path tied to a specific hosting provider
Are there any plans to fix this for the whole language, for others as well? i.e. use namespaces, module names in the source but move the actual github.com, google.com or geocities.com URLs outside.
Re: A new Go API for Protocol Buffers
#74Earlier quoted context omitted.
The goal of issuing a major version is to create a separate package namespace so it can be imported concurrently to other major versions. By treating major versions as different packages, it creates efficiencies in VCS history and common namespace. However, the goal is to create a new package name that can be concurrently imported with previous versions. Everything else is just method. Don't confuse the goal with the…
People care about versions. If it’s harder or more confusing to understand what version you’re on, that’s more than “just method”. Otherwise we’d just use UUIDs for package names and call it a day.
Julia uses uuids masked with name.
Re: A new Go API for Protocol Buffers
#75Not 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…
If you don't have the proto definition, there's nothing you can do except pass the object through unmodified. And you should not need a reflection API for that (unless the v1 API was totally messed up in other ways).
Without the definition (and knowing the type!) there won't be anything around to tell the reflection API what the names, types and annotations are. All you would have is field numbers mapped to opaque blobs of data.
Re: A new Go API for Protocol Buffers
#76It is odd that the Go team is all in on semantic import paths, but basically everyone else is like “I will blow up the moon if it means I don’t have to use v2 in my import path.
I wonder if we will start seeing people add v1.example.com, v2.example.com etc... to their git servers to avoid having to change the path's in all of their private projects.
Re: A new Go API for Protocol Buffers
#77Earlier quoted context omitted.
Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.
Reasoning went something like this: We could tag the new API v2: + Makes the "v1" and "v2" distinction very clear in the import path. - Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does. - In ten years, hopefully nobody cares about the old github.com/golang/protobuf and the confusion is gone. We could tag the new API v1: - Less visually distinct in the import path. + Seems to make sense for the firs…
> - Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does.
This would not be confusing at all. The UUID package I use just skipped from major version 3 to major version 7 to avoid confusion with UUIDv4, UUIDv5 and a possibe UUIDv6. It was well-documented, and even if it wasn't, the upgrade was absolutely painless, as it would have been either way.
Re: A new Go API for Protocol Buffers
#78Hmm. I think it would be quite simple to build an authentication proxy/firewall based on this without having to know the exact underlying message.
Maybe tagging fields with auth_userid and/or auth_token.
Re: A new Go API for Protocol Buffers
#79It is odd that the Go team is all in on semantic import paths, but basically everyone else is like “I will blow up the moon if it means I don’t have to use v2 in my import path.
I wonder if we will start seeing people add v1.example.com, v2.example.com etc... to their git servers to avoid having to change the path's in all of their private projects.
Seems like you need something like a DNS server for repo's.
Re: A new Go API for Protocol Buffers
#80Not 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.
Why not?
> A great example of this is if you want to use dynamically generated protocol buffers.
When would you want to do that? If your data isn't statically typed, isn't it more appropriate to use a type designed for dynamic shapes (e.g. a list or hashmap)?
> A great usecase for this is if you want to store each row in a database as a proto message.
Wouldn't a reasonable approach to this be to turn each row into a list (of variants) and serialize that?