It is interesting to ask why that is the case, from my point of view the reason is that the JVM standard library is just too damn large. While WASM goes on a lower-level approach of just not having one.

To make WASM have the capabilities required the host (the agent running the WASM code) needs to provide them. For a lot of languages that means using WASI, moving most of the security concerns to the WASI implementation used.

But if you really want to create a secure environment you can just... not implement all of WASI. So a lambda function host environment can, for example, just not implement any filesystem WASI calls because a lambda has no business implementing filesystem stuff.

> An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM.

I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster. Or custom WASM runtimes heavily tied to the hardware they run on to make better JIT code.

I imagine a future where WASM is treated like LLVM IR