Get in loser. We're rewinding the stack
8 comments
·February 11, 2025benatkin
That's really impressive. Like the author I am aware of the advantages/drawbacks of emscripten and wasi-sdk. The author did well to look extensively into both of them. Here's the repo. https://github.com/uswriting/zeroperl
As increasingly is the case, a good starting point is the CI workflow: https://github.com/uswriting/zeroperl/blob/main/.github/work...
adolph
Subhead is "Sandboxing Perl with WebAssembly - Part 2."
The subhead sounds weird, but part 1 makes more sense and is pretty interesting. Perl has many modules to deal with file formats nobody has used since Perl's prime. It isn't totally clear to me if the goal is to compile the Perl interpreter into WASM or interpreter + modules. In any either case the goal is to re-use the original tools within new tooling.
I’m building a new startup and file metadata plays an important role. There are thousands of file formats, each format may have dozens of versions, and each stores metadata differently.
Our use-case also needs metadata to be present when a file is uploaded - extracting the data on our servers means we add considerable overhead to upload post-processing & we lose data that is useful to customers.
So we need to extract metadata client-side and staple it to the upload. Herein begins a journey of self-inflicted pain and suffering.
ExifTool is written in Perl.
https://andrews.substack.com/p/zeroperl-sandboxed-perl-with-...
jasonthorsness
Is there anything else in the same class as ExifTool - super valuable but the only implementation is Perl?
Gunax
I do not understand this at all, but it looks cool.
hobs
Honestly it seems like porting ExifTool would actually be easier than this nightmare.
jauntywundrkind
This is a degree of thinking that feels rank common in the world. When you read a complex blog post with sophisticated approach, there's often a "wouldn't it be easy to just ____."
Maybe, yes, perhaps! But sometimes the problem at hand - the proboem specified in the post - isnt the entire desire or objective. "Actually be easier" abounds, but sometimes our scope & intent in the long run builds on the problems at hand.
Porting ExifTool may be easier (but then if you want to maintain it, that's a drain for life). But having perl that you can now run anywhere might be something this author sees other use for. Getting good at wasm or exhibiting their excellent systems skills might have been side objectives.
Whether we just do things to get to get results at hand, or whether we invest ourselves broadly to build a better world is a constant struggle for many engineers. This shows up in the comments time and time again as "would actually be easier". I'm sorry for hitting hard on this specific comment, but there's a Two Cultures problem here, and one culture trivializes the other endlessly in the comments. It's hard for me to state why trying hard & caring & doing extra matters, but I think that breed of people are the ones that I look up to, that make all the difference to me. And I really wish there was a good defense or rallying cry, something we could say when we get the inevitable "would actually be easier" that can capture the enthusiasm for setting ourselves up & building broadly towards our better worlds.
hobs
If it makes you feel good go for it, seems like a huge PITA for me to figure out what files do, but sometimes the journey is a lot more fun than the destination.
setjmp/longjmp in 2025? That's kind of retro.