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.
> 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.
Yes, exactly, and thank you for that!
I don't know of any other general-purpose scripting language that can be run in WebAssembly. This could make Perl an interesting choice for writing sandboxed build system rules.
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.
(it may be less of an issue today since the DPGO will devirtualize those, when profiling average rpc framework, more time is spent on 1. deep async call stacks, 2. inefficient serde that copies data frequently and heap allocates transient objects and 3. working against the language by not using its features made for performance (Memory/Span slices, using manually rolled copy and search routines over span.CopyTo, .IndexOf))
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))
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.
