4 ms·
Upcoming Go protobuf release
- akmittal 9y agowill this fix slow gRPC performance in Go compared to Java/C++ or that is different issue.
- deleted 9y ago[deleted]
- cube2222 9y agoDo you have any sources about gRPC being slow in Go?
- guilhas 9y agoNot sure, but I saw this video: At 26:16 Gopherfest 2017: Upspin (Rob Pike) - https://www.youtube.com/watch?v=ENLWEfi0Tkg https://www.youtube.com/watch?v=ENLWEfi0Tkg
- dfawley 9y agoThat specific problem was resolved in July last year: https://github.com/grpc/grpc-go/pull/1310 https://github.com/grpc/grpc-go/pull/1310 https://github.com/grpc/grpc-go/issues/1043 https://github.com/grpc/grpc-go/issues/1043
- weinzierl 9y agoNothing wrong with Go protobuf, but if you need a lean and mean Protocol Buffers implementation I can recommend Nanopb. It's just a few kB and you can run it even malloc free. [1] http://jpa.kapsi.fi/nanopb/ http://jpa.kapsi.fi/nanopb/
- cjhanks 9y agoHmm, this seems like it might create security leaks for developers using protobuf at public interfaces. They should probably have some kind of static configuration variable `DefaultDiscardUnknown = true`.
- lobster_johnson 9y agoThe three breaking changes are interesting in how, one by one, they describe flaws in the Go language (and I say that as someone whose day job is Go development). The first breaking change means unkeyed literals such as Foo{"bar"} no longer work. This particular Go feature (which arguably came from C) is so open to future compatibility breakage that I wish it had never been included. I prefer Rust's approach here, where fields always have to be speciifed, but a ::new() constructor can be furnished to make fieldless construction possible through the type (as opposed to Go's NewFoo() style which is semantically disconnected from the type). The second one, about structs no longer being usable as map keys or comparable with ==, is a bit more esoteric, but it does demonstrate how Go's type system is too weak to allow such a change to be made without breakage. In Rust or C++, this would presumably have been accomplished with an equality trait, so that the new struct could be made comparable with ==. The third one, about breaking reflect.DeepEqual(), also reveals how the lack of trait support at the language level exposes cracks in the language. When a user is forced to use a blunt tool such as DeepEqual(), which disconnects the equality code from the underlying type being used, then this is what you get. That said, I'm not sure why Protobuf can't optionally generate equality methods for the types it generates in the first place, which is something Gogo can do [1]. Go is a great language, but it's things like this that give me Rust envy. [1] https://github.com/gogo/protobuf/blob/master/plugin/equal/equal.go https://github.com/gogo/protobuf/blob/master/plugin/equal/eq...
- skybrian 9y agoThe protobuf package does provide an Equal function: https://github.com/golang/protobuf/blob/master/proto/equal.go https://github.com/golang/protobuf/blob/master/proto/equal.g...
- lobster_johnson 9y agoIt does, but a method would arguably have been better.
- badtuple 9y agoPardon my ignorance, but is there any functional change by it being a method vs a func? All I can think of is not having to type in the package name to call it and possibly the ability to memoize parts within the struct itself but not sure if you'd even want that in a general solution. If the argument is one of those or aesthetic then awesome, but I'm wondering if I'm missing some difference in how Go handles them.
- ohnoesjmr 9y agoI wonder how this compares with Gogoproto. Nobody in their sane mind uses the standard protobuf package anyway.
- maxaf 9y agoI've been using the standard protobuf package for years, yet I am entirely sane. My mother had me tested.
- agnivade 9y agoThere are no benchmarks yet - https://www.reddit.com/r/golang/comments/7twccr/upcoming_release_of_go_protocol_buffers/dtgc5vn/ https://www.reddit.com/r/golang/comments/7twccr/upcoming_rel...