Since this is Part 1, we merged the comments from the Part 2 thread hither:

Get in loser. We're rewinding the stack - https://news.ycombinator.com/item?id=43014070

Readers may want to look at both articles of course!

Oh I'm so interested in this.

I've wanted to use wazero to run my Exiftool [1] for quite a while. Just as I use wazero to sandbox dcraw [2].

But WASI Perl never materialized.

This may just be what I'm missing.

[1]: https://github.com/ncruces/go-exiftool

[2]: https://pkg.go.dev/github.com/ncruces/[email protected]/pkg...

The ongoing ... lively ... discussion about "wasm all the things" may interest this audience, too: https://news.ycombinator.com/item?id=43020684

"percc" just does not work?

He obviously he meant my perlcc, it is maintained for compatible perl versions and it works and is used in industry.

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.

This guy is just crazy. https://github.com/libexif/libexif exists and is much easier to use than compiling perl to wasm, just to run the overly slow exiftool.

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.

There are security benefits to WASM sandboxing of client-side parsing of untrusted image files, to avoid scenarios like https://imagetragick.com