undefined | Better HN

0 pointstliltocatl1y ago0 comments

> 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.

0 comments

pie_flavor1y ago

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.

tliltocatlOP1y ago

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.

j / k navigate · click thread line to collapse

0 comments

pie_flavor1y ago

tliltocatlOP1y ago

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

j / k navigate · click thread line to collapse