3 ms·

FlatBuffers are already faster than that. But that's not why we choose Protobuf. It's because a megacorp maintains it.

nindalf 8mo ago
You're saying we choose Protobufs [1] because Google maintains it but not FlatBuffers [2]? [1] - https://github.com/protocolbuffers/protobuf https://github.com/protocolbuffers/protobuf: Google's data interchange format [2] - https://github.com/google/flatbuffers https://github.com/google/flatbuffers: Also maintained by Google
- rafaelmn 8mo ago
  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 8mo ago
    > 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 8mo ago
    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
  - dmoy 8mo ago
    > AFAIK they have a bunch of production infra on protobuff/gRPC Stubby, not gRPC. Stubby is used for almost everything internally. gRPC is a similar-ish looking thing that is open sourced, but not used nearly as much as stubby internally. Stubby predates gRPC by like 15 years or something. > not so sure about flatbufferrs which came out of the game dev side I wouldn't know. I'll be honest, I always forget that Google made flatbuffers. I guess if you're doing a lot of IPC?
- cmrdporcupine 8mo ago
  I know it's confusing, but things being under the 'google' namespace on GitHub doesn't mean they're maintained by Google. At least not as an official project. It just means a person working at Google used that avenue to open source them. Google offers a legal few avenues to allow you to open source your stuff while working there but one of the easiest it just to assign copyright to Google and shove it under their GitHub. It just means a Googler published it, not that Google itself is maintaining it. I don't know what the status of flatbuffers is specifically, but I can say I never encountered it in use in the 10 years I worked there. (I use it a lot now on my own things post-Google)
secondcoming 8mo ago
Yet they've yet to release their internal optimisation that allows zero-copying string-type fields.
rurban 8mo ago
I also thought I could trust mega Corp. That's why I put all my code on their platform, code.google.com, and not on this obscure platform without any business model, github. Well, that sucked. And why should I use protobuf, when I just need to share structs and arrays in memory (aka zero copy) with a version field? Like everyone else does for decades?

You're saying we choose Protobufs [1] because Google maintains it but not FlatBuffers [2]? [1] - https://github.com/protocolbuffers/protobuf https://github.com/protocolbuffers/protobuf: Google's data interchange format [2] - https://github.com/google/flatbuffers https://github.com/google/flatbuffers: Also maintained by Google

rafaelmn 8mo ago
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 8mo ago
  > 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 8mo ago
  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
- dmoy 8mo ago
  > AFAIK they have a bunch of production infra on protobuff/gRPC Stubby, not gRPC. Stubby is used for almost everything internally. gRPC is a similar-ish looking thing that is open sourced, but not used nearly as much as stubby internally. Stubby predates gRPC by like 15 years or something. > not so sure about flatbufferrs which came out of the game dev side I wouldn't know. I'll be honest, I always forget that Google made flatbuffers. I guess if you're doing a lot of IPC?
cmrdporcupine 8mo ago
I know it's confusing, but things being under the 'google' namespace on GitHub doesn't mean they're maintained by Google. At least not as an official project. It just means a person working at Google used that avenue to open source them. Google offers a legal few avenues to allow you to open source your stuff while working there but one of the easiest it just to assign copyright to Google and shove it under their GitHub. It just means a Googler published it, not that Google itself is maintaining it. I don't know what the status of flatbuffers is specifically, but I can say I never encountered it in use in the 10 years I worked there. (I use it a lot now on my own things post-Google)

secondcoming 8mo ago

Yet they've yet to release their internal optimisation that allows zero-copying string-type fields.

rurban 8mo ago

I also thought I could trust mega Corp. That's why I put all my code on their platform, code.google.com, and not on this obscure platform without any business model, github. Well, that sucked. And why should I use protobuf, when I just need to share structs and arrays in memory (aka zero copy) with a version field? Like everyone else does for decades?