[klabb3]

> what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code?

If I understand your question correctly, the point is that wasm becomes the agreed-upon target, so you only need language -> wasm compilation and you can then distribute that artifact everywhere. Then you can either JIT it or recompile it into machine code at the endpoint, as an optimization.

That would help reduce the size of the graph of N languages and M architectures from O(MN) to O(M+N) (similar to the function of IR)

[felixgallo]

why would any language besides javascript want to be that maximalist, when they already have either a much better direct native compiler, or their own, purpose-built, mechanically-sympathetic, fully featured interpreter with first-class support and a controllable destiny? We didn't do this with Java back in the day when it was possible -- essentially all but a small handful of JVM languages died on the vine -- so what specifically is different this time?

[mort96]

JVM bytecode is, to my understanding, basically just a serialized, desugared Java. It has a concept of classes with constructors and it has objects and references and inheritance and basically all of Java's semantics encoded in it. Languages which aren't "java-like" have a hard time compiling to it. WASM, on the other hand, is more like machine code, so languages which are used to compiling to machine code have a fairly easy time compiling to it.

[klabb3]

Indeed, not to mention the GC, which isn't one size fits all (not even within Java itself).

And wasm could run in ring 0 if you want, the runtime is that hardened.

[miohtama]

You can “already” run Wasm modules in kernel to speed up things

https://github.com/wasmerio/kernel-wasm

[int_19h]

We didn't do it with Java because JVM bytecode is very narrowly tailored to Java. For example, it doesn't have the notion of pointer arithmetic, for example, so you can forget about anything like C (one can emulate heap as a Java array and build the rest on top of that, of course - but only if performance doesn't matter).

On the other hand, wasm is low-level enough to handle C.

.NET / CLR was the previous attempt to do something like this, and it did have compilers for many different languages targeting it. But the downside there was that the runtime itself wasn't meaningfully portable for a very long time. If it were open and cross-platform from the get go, who knows, perhaps wasm would have been a CIL subset.

[phickey]

The security properties are ultimately why we invested in WebAssembly. We (Fastly; the author is my colleague) run very large numbers of WebAssembly modules, all in the same process where the plaintext HTTP requests and responses from very large numbers of our customers reside, without needing to trust the authors of those modules. There are many technologies for running untrusted code out there, and we picked WebAssembly because we can make it fast in all the ways this article details without compromising on security.

Stay tuned, the next article in this series on Wasmtime security will run next Tuesday.

[nextaccountic]

> all in the same process where the plaintext HTTP requests and responses from very large numbers of our customers reside

The security of this looks very very fragile. Practically any vulnerability may leave the requests of all customers unprotected.

Compare with the common practice of isolating each customer on its own address space or, better yet, on their own VM, requiring a privilege escalation vulnerability (which is much rarer) to eveasdrop on other processes or VMs running on the same computer

edit: now, if you're running each wasm module on a separate process, sandboxed with seccomp-bpf, now that's another thing entirely, and might be more secure AND more performant than traditional VMs