4 ms·
> Everyone is focused on targeting WASM with several languages but is missing the big problem: lack of a standard library I'm not so sure that's a problem that
by hackcasual 9y ago
> Everyone is focused on targeting WASM with several languages but is missing the big problem: lack of a standard library
I'm not so sure that's a problem that would benefit WASM to solve. Right now the imports Emscripten provide are the defacto standard lib, which does shape how other projects approach WASM.
I feel a large reason behind seeing so many interesting toy projects that use WASM (and it's quick cross browser adoption) is due to it having such a small scope. Define a portable, easily optimizable VM.
The big challenge there is to support higher level concepts like GC, you need to make that work at a machine level, not a standard library level.
- kodablah 9y agoAgreed it is not for WASM to solve. I'm just stating the ecosystem issue because everyone thinks compiling their favorite language to WASM provides immediate interoperability.
- wrmsr 9y agoWhen I was working on it the accepted solution was to compile as linux and statically link musl into the wasm binary, leaving mostly __syscallN symbols unresolved. As such it's a matter of implementing those on an as-needed basis (in javascript for emscripten and in java here). I at least successfully got sqlite opening a database in a pure java transpile that way. While it's a possibly inelegant approach on the face of it linux does at least have an aggressive 'dont break userspace' attitude and there is longstanding prior art for this on freebsd. see: https://github.com/kripken/emscripten/blob/6dc4ac5f9e4d8484e273e4dcc554f809738cedd6/src/library_syscall.js https://github.com/kripken/emscripten/blob/6dc4ac5f9e4d8484e...
- hackcasual 9y agoAh, gotcha. I'm looking forward to seeing what non-Emscripten stuff grows to support WASM.