Wait a second...
I thought Java was supposed to do this with the JVM...
I thought .Net was supposed to do this with the CLR...
What's different now?
I thought Java was supposed to do this with the JVM...
I thought .Net was supposed to do this with the CLR...
What's different now?
They put in huge amounts of effort into things that don't need solving, and the things that need to be solved they do in the most roundabout way possible.
What we _really_ need is a sandboxed VM for running C code securely and efficiently.
The JVM is pretty much the opposite of that; it's not sandboxed, not secure and certainly not efficient as a target for C code.
We're hoping WASM starts over from scratch and does things right this time around.
JVM, CLR, and WASM suck balls. People have been breaking the sandbox for the better part of a decade.
We're hoping Cool New Thing™ starts over from scratch and does things right this time around.
I mean, maybe they really will be, but history suggests otherwise.
Android apps are sandboxed Java apps.
Containers turn almost any Linux process into a sandboxed process.
Am I wrong ?
I did evaluate WASM as a native runtime environment recently, pre-WASI. If what you're doing can coexist with memory mapped I/O, you don't have to have an explicit interface of this type, you can just say "lower region of linear memory is where the I/O goes" and hardcode all APIs against that. It's more "honest" in certain ways than a syscall interface since it doesn't lead to any parsing of intent or variable expectations around resource usage.
It can be an enabler for new innovations. Even if it runs 2-10x slower than native code.
And what if the answer was just: just because I can? That's how a lot in our industry got started.
Honestly, it shouldn't need to be that big. There's plenty of cruft even in .NET core.
Anything other than Electron if it comes to it
If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here.
As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely in native environments. I'm a younger developer and only partly remember the days of Java on the web, but is there a reason for why JVM is not suitable in web environments? I.e. why WebAssembly -> Native, not JVM -> Web?
I'll take a stab at it. While both WASM and the JVM aim to be portable virtual machines, WASM prioritizes sandboxing / security and a smaller runtime. A host should be able to easily set up WASM with restricted access and expect that the WASM program is secure. As far as I know, the JVM doesn't have an equivalent feature, or if it does, it's a lot more complicated.
On the other hand, I seem to remember that the security model was (somewhat) adapted to the threat at hand when it was designed (~25 years ago). I haven't kept tabs on it, so I don't know how well it has aged, but there's a chance it doesn't work anymore.
1. WASM is an open standard
2. WASM spec is smaller, so it's easier to integrate into the Javascript VM, which itself brings many benefits
Since WASM wins on the web, I guess it makes sense for developers to want to develop one version of their code for both the web as well as native environments. Thus, WASM -> Native seems to totally make sense.
[0] https://words.steveklabnik.com/is-webassembly-the-return-of-...
So is the web, but that didn't stop anyone from extending it in incompatible ways and all implementations being subtly different enough that you still have care about which one you're running on and, oh yeah, it's also becoming dominated by a single player who steers the whole thing pretty much wherever they want it.
JVM is pretty complicated and not open source(? I'm not entirely sure who owns the standard, if there is one). WebAssembly has the advantage of hindsight and being able to be designed to completion rather than evolved
The JVM and CLR seem like they're language platforms first and VMs second
Ding ding ding ding ding.
There are lots of extant application VMs out there, but effectively all of them were implemented specifically to be able to run a specific language (Java → JVM, C# → CLR, Perl 6 → Parrot/NQP/whatever, Erlang → EVM/BEAM, etc.). Other languages have been implemented on top of those VMs, but they have to adopt the semantics of the actually-targeted language; you'd have a hard time taking a pure C codebase and compiling/running it on the JVM or CLR or BEAM.
WebAssembly is not that much different, technically; its actually-targeted languages are C, C++, and Rust, and you can reasonably think of it as a VM for those languages. However, it seems to be making an effort to not get caught up in the semantics of any specific language, much like how machine code tends to not really care about whether the instructions it's executing were compiled from C or Rust or Java or Ruby or COBOL or Brainfuck.
Parrot was intended as a more universal VM, and was started before the Perl6 design solidified. So in the end it didn't actually fit that well with Perl6.
NQP is a small subset of Perl6 that is used for bootstrapping Perl6, and provides an isolation layer from the vagaries of the various VMs it targets. It used to target Parrot, and now targets MoarVM, the JVM, and JavaScript. (NQP is an acronym for Not Quite Perl6.)
MoarVM (Metamodel On A Runtime) was built specifically for Perl6, but its design is minimal. Most of the Perl6 specific features are built using Perl6 and NQP.
For example, MoarVM only provides only enough of an object/type system to bootstrap the full object system. That is MoarVM gets taught how Perl6 objects work every time it loads the Perl6 runtime.
MoarVM also has a pluggable optimizer where you write the plugins in a higher level language. It could be any language that compiles down to MoarVM bytecode. The Perl6 ones are written in NQP.
I think this dynamism makes MoarVM an interesting target for other languages.
Or, more accurately, its easy to make UIs for it?
I'm personally bearish on the whole idea from a community / technical standpoint (in that I'd like us to return to more native stuff than follow JS into the browser), but I can't argue that WASM and co won't enable some really cool uses.
My takeaway from WASI is that it would allow for a single universal runtime with near-native execution. The near-native aspect being what other universal runtimes like the JVM and CLR lack due to their bundling of a GC and other non-essential features.
On top of that, JS devs would be the ones who get the short end of the stick, because js is the one language that does not compile to WASM because where WASM comes from, you already have a JS environment, no need to build a second one inside WASM.
Node always struck me as a strange trend but using web tech for UIs seems like a good fit for a lot of cases