| ▲ | yodacola 6 hours ago |
| FlatBuffers are already faster than that. But that's not why we choose Protobuf. It's because a megacorp maintains it. |
|
| ▲ | nindalf 6 hours ago | parent | next [-] |
| You're saying we choose Protobufs [1] because Google maintains it but not FlatBuffers [2]? [1] - https://github.com/protocolbuffers/protobuf: Google's data interchange format [2] - https://github.com/google/flatbuffers: Also maintained by Google |
| |
| ▲ | rafaelmn 6 hours ago | parent [-] | | I get the OP is off base with his remark - but at the same time maintained by Google means shit in practice. AFAIK they have a bunch of production infra on protobuff/gRPC - not so sure about flatbufferrs which came out of the game dev side - that's the difference maker to me - which project is actually rooted in. | | |
| ▲ | dewey 6 hours ago | parent | next [-] | | > but at the same time maintained by Google means shit in practice. If you worked on Go projects that import Google protobuf / grpc / Kubernetes client libraries you are often reminded of that fact. | |
| ▲ | whoevercares 4 hours ago | parent | prev [-] | | Flatbuffers are fine - I think it is used in many places that needs zero-copy. Also outside google, it powers the Arrow format which is the foundation of modern analytics |
|
|
|
| ▲ | secondcoming 6 hours ago | parent | prev [-] |
| Yet they've yet to release their internal optimisation that allows zero-copying string-type fields. |
