News for hackers. Stuff that matters.
Re:Bebop v3: a fast, modern replacement for Protocol Buffers by martinky24 on Tuesday March 12, 2024 @11:38AM (#39680810)
Are protocol buffers not considered "modern" or "fast" anymore? How time flies...
Re:Bebop v3: a fast, modern replacement for Protocol Buffers by andrew_rfc on Tuesday March 12, 2024 @11:47AM (#39680934)
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.

Re:Bebop v3: a fast, modern replacement for Protocol Buffers by martinky24 on Tuesday March 12, 2024 @12:25PM (#39681378)
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.
Re:Bebop v3: a fast, modern replacement for Protocol Buffers by TexasMick on Tuesday March 12, 2024 @01:44PM (#39682496)
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.

Re:Bebop v3: a fast, modern replacement for Protocol Buffers by throwaway143829 on Tuesday March 12, 2024 @05:20PM (#39685113)
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.

Re:Bebop v3: a fast, modern replacement for Protocol Buffers by flohofwoe on Tuesday March 12, 2024 @01:00PM (#39681924)
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 ;)
Re:Bebop v3: a fast, modern replacement for Protocol Buffers by martinky24 on Tuesday March 12, 2024 @01:20PM (#39682177)
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.
Re:Bebop v3: a fast, modern replacement for Protocol Buffers by mst on Tuesday March 12, 2024 @01:44PM (#39682499)
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.

Re:Bebop v3: a fast, modern replacement for Protocol Buffers by johnisgood on Thursday March 14, 2024 @08:23AM (#39702962)
And here I am using ASN.1 for a couple of new projects. :P
Re:Bebop v3: a fast, modern replacement for Protocol Buffers by martinky24 on Thursday March 14, 2024 @10:26AM (#39704450)
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.
Re:Bebop v3: a fast, modern replacement for Protocol Buffers by johnisgood on Thursday March 14, 2024 @01:38PM (#39706819)
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?

Re:Bebop v3: a fast, modern replacement for Protocol Buffers by martinky24 on Thursday March 14, 2024 @02:44PM (#39707502)
Mostly C++ and Python. Using some home-built stuff for now...