4 ms·
just curious, why do use protobuf instead of flatbuffers?
by g0ld3nrati0 2y ago
just curious, why do use protobuf instead of flatbuffers?
- tonyhart7 2y agoYeah idk why we didnt just send binary data representation therefore eliminate entire serialize and deserialize part
- tsimionescu 2y agoWhich binary data representation? If I'm sending a Java object, do you think a C program will be able to just use it? Or for that matter, do you think two different C++ implementations, maybe on different platforms, will use the same binary representation of a class object?
- tonyhart7 2y agojust need an standard for that
- tsimionescu 2y agoJava has a standard, each C implementation has a standard, Python has a standard, etc. The problem is that each of these standards is different, and impossible to modify. So, we need something that can serialize one standard to a wire format, and then deserialize from that wire format to another standard. Oh wait...
- tonyhart7 2y agoso we cant create a standard that can eliminate serde part????
- tsimionescu 2y agoI'm assuming you may be trolling me, but no, that can't realistically be done.
- tonyhart7 2y agoseems like skill issue to me
- coryrc 2y agocap'n proto does IIUC
- akshayshah 2y agoThe whole FlatBuffers toolchain is wildly immature compared to Protobuf. Last I checked, flatc doesn’t even have a plugin system - all code generators had to be upstreamed into the compiler itself.
- mort96 2y agoIsn't protoc mostly the same? I mean I know the code generators are separate binaries (which is quite annoying frankly) but protoc needs to know of them all upstream to expose options like --go_out and --go_opt, right?
- Zababa 2y agoI'm not sure. We have a few private plugins at work and they work fine with regular protoc. I think the --go_out and friends are automatically created by the plugins. Something like, they declare themselves as "toto" and to protoc now has a --toto_out option.
- mort96 2y agoI see, interesting!
- akshayshah 2y agoNo, that's not the case - there's a standard to how protoc exposes plugin options as CLI options that doesn't require the compiler to know about each plugin. It's obtuse, annoying, and badly documented, but it's there :) The whole situation is extra confusing because some of the core codegen plugins are built into protoc. That's a distribution and version-matching strategy from the Google team rather than a requirement of the plugin system. I'd very much like Google to ship the built-in plugins as standalone binaries, even if they're also bundled with protoc.
- majormajor 2y agoIf you work with both the ergonomic advantages of protobufs become quickly apparent - starting the first time you nest things a few times. Unless you are very very frequently not going to deserialize your entire messages and so can get huge benefits from the better selective-deser of only what a given consumer cares about at a certain time, I find using flatbuffers hard to justify.