Why is 'more memory safe than just having the application running in a separate process' the benchmark? Literally nothing can clear that bar. It is more memory safe than most existing VM languages, which is all anyone actually cares about.
That's just not true. Every language that doesn't allow casting pointers to integers (that is, JVM, Javascript, Python and literally everything but C/C++) is more memory-safe that WASM. Yes, performance on these more or less sucks. But what I'm trying to tell, the only advantage WASM has over native code is portability, it's no more safe than native code, most interpreted languages (where "interpreted" includes bytecode and JIT) are safer.
No, they aren't. The host is equally memory safe with a WASM guest as with any other fully sandboxed embedded system, of which Java is not. And everything you mentioned isn't any more memory safe running in the same process as in a foreign process, which was, again, the bar you set.
I think we disagree on what memory safety is. For me, memory safety is about "not being able to type-pun pointers and access stuff out-of-bonds", rather than just "isolate address spaces".
> fully sandboxed embedded system, of which Java is not
How so? Nothing stops JVM from sandboxing within the same address space. Then the java API breaks sandboxing in many intended and unintended ways, but the advantage of WASM here is that it doesn't provide a standard API at all - every attempt to provide same functionality will run into similar issues.
