3 ms·

Are protocol buffers not considered "modern" or "fast" anymore? How time flies...

andrew_rfc 3y ago
They were never particularly all that fast, especially not in the browser where support is far from acceptable. Most implementations rely on runtime magic, reflection, and other hacks. So in that sense they aren’t all that modern as they’ve failed to evolve and keep up with platform evolutions. Bebop just aims to generate code that modern and current with its target language, works everywhere, and avoids pitfalls protobuf suffers from.
- martinky24 3y ago
  I see. So far protobufs have met my needs and I've been happy with them, but I've used them more in an RPC context and less as a browser based data unit, so that makes sense.
- TexasMick 3y ago
  I benchmarked protobuf encoding and nanopb was very good. Even though our schema was huge, it still did serialisation in a time that was surprisingly small for our underpowered chip.
- throwaway143829 3y ago
  Have you seen protobuf.js? I've dug quite deep into its generated code and have not seen any runtime magic. It's just directly working with the protobuf wire format and transferring the data to/from fields with very explicit code. I can't speak for Google's official implementation though.
flohofwoe 3y ago
Not sure if it has improved in the last few years or if other target languages are better, but the protobuf code generation for C++ was pretty much the worst C++ code in terms of bloat I have ever seen. And I've seen a lot of bad C++ code ;)
- martinky24 3y ago
  In what ways did that meaningfully matter though? I use generated C++ protobuf code, and the API is clean even if the implementation looks like it wasn't hand written? If you think the C++ code is bad, you should see the Python... But again, the APIs are clean and robust so it hasn't affected me.
  - mst 3y ago
    The "bloat" part is probably going to impact your compile times. Also I tend to want generated code to be at least ish comprehensible in case I need to debug into it - from what you're saying, everything has gone sufficiently well in terms of 'clean and robust' that that hasn't been an issue for you in practice ... but justified or not, it's going to worry me anyway.
johnisgood 3y ago
And here I am using ASN.1 for a couple of new projects. :P
- martinky24 3y ago
  Out of curiosity, what tooling are you using around ASN.1 for language interoperability? I haven't found a "gold standard" that I'm happy with yet, personally.
  - johnisgood 3y ago
    Same, to be honest. I mainly use it with both Erlang and Java / Kotlin. While Erlang has excellent support for ASN.1, I have found that Java / Kotlin lacks adequate free tooling for working with it, which is quite surprising. Which programming languages do you have in mind?
    - martinky24 3y ago
      Mostly C++ and Python. Using some home-built stuff for now...

They were never particularly all that fast, especially not in the browser where support is far from acceptable. Most implementations rely on runtime magic, reflection, and other hacks. So in that sense they aren’t all that modern as they’ve failed to evolve and keep up with platform evolutions. Bebop just aims to generate code that modern and current with its target language, works everywhere, and avoids pitfalls protobuf suffers from.

martinky24 3y ago
I see. So far protobufs have met my needs and I've been happy with them, but I've used them more in an RPC context and less as a browser based data unit, so that makes sense.
TexasMick 3y ago
I benchmarked protobuf encoding and nanopb was very good. Even though our schema was huge, it still did serialisation in a time that was surprisingly small for our underpowered chip.
throwaway143829 3y ago
Have you seen protobuf.js? I've dug quite deep into its generated code and have not seen any runtime magic. It's just directly working with the protobuf wire format and transferring the data to/from fields with very explicit code. I can't speak for Google's official implementation though.

flohofwoe 3y ago

Not sure if it has improved in the last few years or if other target languages are better, but the protobuf code generation for C++ was pretty much the worst C++ code in terms of bloat I have ever seen. And I've seen a lot of bad C++ code ;)

martinky24 3y ago
In what ways did that meaningfully matter though? I use generated C++ protobuf code, and the API is clean even if the implementation looks like it wasn't hand written? If you think the C++ code is bad, you should see the Python... But again, the APIs are clean and robust so it hasn't affected me.
- mst 3y ago
  The "bloat" part is probably going to impact your compile times. Also I tend to want generated code to be at least ish comprehensible in case I need to debug into it - from what you're saying, everything has gone sufficiently well in terms of 'clean and robust' that that hasn't been an issue for you in practice ... but justified or not, it's going to worry me anyway.

johnisgood 3y ago

And here I am using ASN.1 for a couple of new projects. :P

martinky24 3y ago
Out of curiosity, what tooling are you using around ASN.1 for language interoperability? I haven't found a "gold standard" that I'm happy with yet, personally.
- johnisgood 3y ago
  Same, to be honest. I mainly use it with both Erlang and Java / Kotlin. While Erlang has excellent support for ASN.1, I have found that Java / Kotlin lacks adequate free tooling for working with it, which is quite surprising. Which programming languages do you have in mind?
  - martinky24 3y ago
    Mostly C++ and Python. Using some home-built stuff for now...