I spent a few days brute forcing tables before I came across your repo and it finally clicked what was actually going on; thank you so much!
228 karma · joined April 6, 2023
Support has languished because the language changed fast enough that it never kept up. It may be used in the industry, but for a modern Perl application (or anything past 5.10) it won’t work. Hence why it was removed.
Speaking of - libexif doesn’t support a lot of file formats, whereas ExifTool does.
If I always opt to choose the easiest path then I’m setting a precedent for myself that I will compromise on all my goals for half finished solutions that take me further from initial idea.
By completing this work, I can use ExifTool in any environment now - and more broadly, there is now a portable, embeddable, and sandboxed version of Perl that others can use in their projects. I can think of a lot of use cases, and helping other developers makes any hardship I endured worth it.
And I can tell the C# code it generates is going to be plagued by vtable lookups. Some decent ideas though.
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.
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.
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’m also working on a textual configuration language that allowa you to import a schema and define data like JSON.
- 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.)