alt Hacker NewsI've been working on a server-side wasm impl of cpython called boomslang [1] and have been thinking a lot lately about packaging, one of the downsides of my current impl is the need to statically link all c/rust extensions. Its too bad IMO how much of the wasm ecosystem targets/depends on emscripten directly. It'd be interesting to see if a more generic ABI could be provided for non emscripten/js based wasm runtimes.
Replies
wasi 0.3 just came out and its fully component model based with no emscripten specific parts. also supports dynamic linking in the spec but afaik no runtime actually has it implemented in a released version.
I think one of the issues is that WASM is notoriously hard to generate code for because they decided to use an IR that's fundamentally incompatible with literally any existing native compiler backend's IR (not counting very specialized ones or toy direct-ast-to-machine-code compilers).
It feels like nobody actually consulted actual compiler writers when designing this. I'm sure that isn't true, but it definitely feels that way. (I suspect the truth is that they were consulted, but ignored.)
It means codegen needs to resort to all sorts of hacks (like the relooper) in order to target WASM, a property not shared by any other target.
And apparently, the way they handle variables also results in deoptimization, though I don't recall the details of that.
Add the fact that interacting with the browser on the web still has to go via JavaScript to this day (for the most part, at least), and, well.
---
TL;DR a combination of poor IR design that has a massive impedance mismatch with pre-existing compilers (and most new ones, because it turns out there's a reason the WASM approach isn't standard) plus WASM still being a second-class citizen in its supposed primary environment (the 'W' in WASM) --- the former ensures targeting it consumes a lot of resources/time, the latter ensures the bar for that to be worth it is much higher.
You can target most architectures with little trouble (at least a a baseline --- optimization's a hard problem regardless of target, except maybe SPIR-V due to the recommendation that pre-optimization is limited in scope). But WASM is completely out there, it's closer to trying to target e.g. Java (not JVM!) at the backend instead of machine code or some other IR.
You don't make an IR intended to be targeted by existing/native compilers by making it completely different to anything they had to target before and completely different to their own IRs and representations ... unless you're the guys behind WASM.
The WASI support in CPython has moved along very well and it is an early target via componentize-py[1]. Notes on WASI support in Python can be found in PEP 816[2]; CPython will be jumping from 0.1 to 0.3 (0.2 is adapted in componentize-py) which should unlock a fair bit of support, especially once cooperative threads lands (providing a pthreads impl in wasi-libc).
[1] https://github.com/bytecodealliance/componentize-py [2] https://peps.python.org/pep-0816/