Hacker News Reader

Comment by g0ld3nrati0 | Hacker News Reader

just curious, why do use protobuf instead of flatbuffers?

The 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.

Isn'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?

No, 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.

I'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.

I see, interesting!

If 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.

Yeah idk why we didnt just send binary data representation therefore eliminate entire serialize and deserialize part

Which 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?

just need an standard for that

Java 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...

so we cant create a standard that can eliminate serde part????

I'm assuming you may be trolling me, but no, that can't realistically be done.

seems like skill issue to me

cap'n proto does IIUC

Reply on news.ycombinator.com