Would this require using the WASIX libc? I didn’t spend much time on it, but when I attempted to use it the build started failing in mysterious ways - happy to open an issue on the relevant repo with a reproduction / notes on what I think our some bugs.
You cannot today build anything on the Blead of Perl with perlcc.
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.
I’m not sure where you got the idea it’s slow, but it executes within 30% of native speed. Which means extracting the metadata from a 30 GB pro video in my test takes 300-400ms.
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.
Author here: it wouldn't have been. Sure, it would be nice to have a native version, but that is a lifelong maintenance burden, and ExifTool is already the best at what it does and stays up-to-date with file format changes.
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.
In its current state it’s mostly just something fun to toy around with if you’re interested in game engine development; once it’s more mature I’ll probably ship a game on it. I have POC multi-player setup where you can telnet to a box and join a 3D world with other users.
Apologies if my initial comment came off the wrong way; when I say “not alternatives” I was injecting bias into that statement since I normally use Cap’n Proto on embedded and memory constrained systems (amazing library btw.)
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.
you get forward and backwards compatibility out of the box so long as you adhere to the schema guidelines.
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 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.
If we’re talking specifically about C# binary serialization I’d recommend checking out this independent benchmark another developer did comparing Bebop to everything else
We don’t benchmark against FlatBuffers or Cap'n Proto for a few reasons:
- 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.)
The benchmarks are in the repo + provided as screenshots in the README, but to clarify this is speaking to performance improvements relative to v2 of Bebop.