Does it matter? I don't really see the issue with competing standards if the standards are open: The "best" (for some definition of best) should win out eventually.
We could re-implement C as well, but is it sensible if we already have C?
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've now found a blog post[0], which seems to outline two main reasons for WASM over JVM on the web:
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.
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.
Someone correct me if I'm wrong, but don't the JVM and CLR assume they're working with GC'd languages and a number of other things? Making them poor targets for many languages, and AFAIK a WASM runtime is a lot more lightweight than both of them
The JVM and CLR seem like they're language platforms first and VMs second
"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.
Makes me wonder: is there any language implemented on the JVM that works around the JVM GC the way asm.js works around the js GC? Would it even be possible, could it be performant?
Early Blazor prototypes used a compact .NET runtime (including assembly execution, garbage collection, threading) that compiled to a mere 60KB of WebAssembly. They moved to mono, so that isn't true now.
> 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.
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.
If something, be it a language or a VM is not up to scratch, it would seem to be a good idea to reimplement it. Would you propose just sticking with the mediocre present instead?
Yes. C is an absolutely terrible programming language that we use because it got their first. I sincerely hope that C (and bad C++, so probably C++ as well) is phased out over the coming years purely because it's too dangerous to use it in critical software (One life lost to memory corruption is too many). This probably won't happen, but I hope it does.
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
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?