Mozilla announces WebAssembly System Interface, what JVM should have been

It's kind of true -- it's designed with a recognition that computers are real things, and shouldn't be abstracted out in terms of a specific programming model. The JVM approach (somewhat by design) limits the easer of interaction with other systems.

The biggest drawback in WASM to me has alway been the memory model. While it is memory safe, it's currently opaque to the host environment which means that the general implementation is to over allocate address space and essentially implement pointers as integers. That results in pointers that can't be trivially shared between environments.

That said, I think that if I /were/ to be making an app that had plugins, or an OS from scratch, etc I would define an interface via WASM. Screw loading unbound untrusted code into my process. My code is 100% bug free, I don't want to other people to break it.

This is not remotely true :D

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article:

> ...you can't run Java code in a browser without a plugin...

> ...WASM, being memory safe and tuned for validation, also has security advantages over Java applets...

> ...explained the difference between WebAssembly and Java thus: "WebAssembly has been designed to scale from tiny devices to large server farms or CDNs...

> ..."That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link...

> ...But a write-once, run anywhere binary represents a worthwhile effort...

1. is true

2. Yeah, I read that and was super confused. Literally that was one of the main point of the Java language itself, enforced by the JVM itself.

3. I think this is more a matter of expected level of abstraction, but I agree this is fairly weak.

4. This just seems like standard "the new thing is vastly superior to the old thing", with a valid touch of "the JVM is too heavily abstracted from how computers work"

5. Yeah, this was also weird.

The underlying problem is what the threat model was - in Java/JVM a significant amount of effort was put into addressing "what if the byte code itself is malicious", with the core applet VM having quite a lot of power over the system - e.g. file I/O, GPU access, etc.

> I am biased here.

Haha, I'll defer to you then. But I'm still curious about this:

> you have to support arbitrary compiled code, with all the intentional or unintentional memory safety violations

But there are multiple barriers here, are there not? First, your code needs to be signed (and notarized, at some point), and then at runtime the app sandbox/entitlements/process separation ensures there's not much you can do even if you're running arbitrary code. Sure, the first "barrier" isn't necessarily all that restrictive or thorough, but the other one should ideally stop anything horrible?