Bebop v3: a fast, modern replacement for Protocol Buffers
github.com
github.com
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.
I can't speak for Google's official implementation though.
Even though our schema was huge, it still did serialisation in a time that was surprisingly small for our underpowered chip.
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.
Which programming languages do you have in mind?
I’m also working on a textual configuration language that allowa you to import a schema and define data like JSON.
And all the time I use JSON, there don't exists multiple versions and any JSON file that is somewhere can get read by almost every language. (And I can read the file even with every editor)
I’m not really in the market for another proprietary binary data format that doesn’t integrate with anything outside its immediate ecosystem.
Update: Coming soon!
And I can tell the C# code it generates is going to be plagued by vtable lookups. Some decent ideas though.
And overall observation is the less code and the simpler it is, the better, notably gRPC suffers from its pipeline/interceptors-support style implementations and insisting on usings its own types replacing T[] and List<T>, putting irreducible mandatory cost in places where it may matter most (unless you partially bypass those with reflection/unsafe accessor like I had to do once))
It's nice to finally see some quality alternatives to Protobuf.
One idea I like from Slice are custom types. Is there anything similar in Bebop?
The docs go into more detail on how different types are handled. We also have some special features like “binary schema” which let you ship your schema with data so clients are always up to date.
They aren’t relevant to what Bebop is doing and thus no benchmark or comparison can be made between them.
The main limitation of Cap'n Proto compared to Protobuf is the ecosystem -- missing or poor-quality implementations in many languages, limited tooling, etc. Admittedly this is probably a showstopper for most users. It's also the hardest thing for any new contender to solve.
With all that said I would tend to agree that benchmarks are probably pointless. I've spent a lot of time benchmarking serialization and one thing I know is that benchmark results will vary wildly depending on the use case. A benchmark of an example/toy use case isn't really indicative of performance in a real use case.
(I'm the author of Cap'n Proto. I don't know much about Flatbuffers so can't comment there.)
When I created Bebop years ago I tried to benchmark it against Cap’n Proto, but the lack of a semi-decent web or C# implementation mentally made me recategorize.
So I suppose I’m just comparing what’s closest in terms of ecosystem support rather than a purely functional level.
It obviously doesn't make sense to benchmark a JavaScript Bebop implementation against a C++ Cap'n Proto implementation, nor does it make sense to compare against a JS Cap'n Proto implementation written by a third-party contributor that is incomplete and unmaintained... so there isn't really a sensible comparison to make.
Flatbuffers immediately compares itself to protobufs as well on the front page.
Sorry, but I would like some benchmark data to these claims....
- They are impossible to benchmark against each other without making an assumption about how often you want to access the data, and which parts of it you want to access. But this means Bebop, Cap'n Proto, FlatBuffers can exist side-by-side / solve different problems: what FlatBuffers and Cap'n Proto do makes sense if you want to access only parts of your objects in limited specific ways, what we do is better if you're always interested in the whole packet.
- We don’t benchmark against Capt’n Proto because it does not have a stable web-based implementation, at least not one that has the features that make it so fast natively, so there is nothing to compare.
Basically, Bebop is great for message oriented applications or where you need the entirety of your packet deserialized in a single step. So we can only benchmark against similar formats (JSON, Protobufs, MsgPack, etc.)
You will be better served by gRPC and, if you need absolute maximum performance, MemoryPack (it is C#-first but can generate TypeScript clients).
If you need MQ, NATS is a good choice (special kudos to them adopting Yoshifumi Kawai's AlterNATS into NATS v2 C# client implementation).
(and by deprecated I mean deprecated 5+ years ago like in the case of Utf8Json)
Sadly a lot of videos discussing performance do only limited research and do not approach the matter comprehensively (likely not worth it for YT algorithm favoring quick and easy content).
Nothing wrong with offering your own first-party use cases that attempt to simulate realistic workloads on top of suggested patterns for each respective contestant, but it is important to include more performance-oriented frameworks/libraries (which is why I mentioned MemoryPack) that are used e.g. in gamedev sphere which cares a lot about realtime communication.
With all that said, it's actually awesome to see a framework that offers first-class C# support, so I probably need to shut up and appreciate the fact :)
I mean... not compared to protobuf.
> unmaintained,
The C++ implementation is well-maintained and heavily used by its own maintainers (e.g. me). Other implementations are maintained to varying degrees, since each implementation has a different maintainer. Agreed the C# implementation isn't maintained.
> You will be better served by gRPC
Well, this really depends, considering that Cap'n Proto's RPC system is quite different and far more expressive than gRPC.