You can compile Rust/C/etc executables to it, the stdlib might be different or nonexistant (unclear to me), WASM doesn't have a GC (yet) and you can get stacklike semantics, probably fewer security holes, the installer probably doesn't bundle other softfare.
But yes, technically speaking it's not that much different from JVM bytecode execution. Software is more consensus than breakthroughs though, so WASM might succeed where Java failed (well, kind of) because we're ready for it and the major players want it.
For people who like the idea, check Terrarium[1] from Fastly. They use Wasmer with Fastly services to have edge computing capabilities. Think AWS Lambda but in a CDN. It looks promising!
Surely they’re not using wasmer. They’re using cranelift with their own runtime, correct? This talk mentions a cranelift runtime fastly built in-house. https://youtu.be/FkM1L8-qcjU
Doesn't WASM interface with a JS/WASM VM, which is then responsible for interfacing with the OS? There are plenty of POSIX compatible VMs, including V8, the Chrome engine.
The "posix" needs to be on the other side. Things like v8 use a posix interface for interacting with the OS. However they don't provide a posix interface the code which is running inside the VM.
I think what was needed was that someone implemented posix APIs inside webassembly, by delegating to the javascript APIs that e.g. node.js provides, or by building a native module that proxies those calls.
They both should have very similar numbers in performance.
Right now there is a bit of slowdown at startup time because of function compilation, but we are planning to improve this quite soon!
We first wanted to focus on running Emscripten-generated WebAssembly files, so we are wrapping the syscalls that Emscripten is using with the real syscalls under the hood.
I'm not very well informed but I assume that you just call functions which are implemented by the VM, in the same manner you do filesystem operations in nodejs.