3 ms·
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
by pie_flavor 2y ago
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.
- deleted 2y ago[deleted]
- tliltocatl 2y ago> Literally nothing can clear that bar. 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.
- pie_flavor 2y agoNo, 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.
- tliltocatl 2y agoI 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.