5 ms·

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

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?

nepeckman 8y ago
> 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.
- pjmlp 8y ago
  Nah, just bytecode verifiers, security managers and access capabilities, but whatever.
- Yoric 8y ago
  It really very much has :) 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.
emerongi 8y ago
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. [0] https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
- AnIdiotOnTheNet 8y ago
  > 1. WASM is an open standard 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.
nutjob2 8y ago
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?
mhh__ 8y ago
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
- saagarjha 8y ago
  OpenJDK is GPLv2.
McWobbleston 8y ago
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
- yellowapple 8y ago
  "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.
  - usrusr 8y ago
    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?
  - b2gills 8y ago
    Some points of note: 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.
EmpirePhoenix 8y ago
Is it just me, or do I kinda feel the jvm running on wasm already? Even the uis would work by rendering via canvas in software ...

nepeckman 8y ago

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

pjmlp 8y ago
Nah, just bytecode verifiers, security managers and access capabilities, but whatever.
Yoric 8y ago
It really very much has :) 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.

emerongi 8y ago

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. [0] https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...

AnIdiotOnTheNet 8y ago
> 1. WASM is an open standard 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.

nutjob2 8y ago

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?

mhh__ 8y ago

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

saagarjha 8y ago
OpenJDK is GPLv2.

McWobbleston 8y ago

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

yellowapple 8y ago
"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.
- usrusr 8y ago
  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?
- b2gills 8y ago
  Some points of note: 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.

EmpirePhoenix 8y ago

Is it just me, or do I kinda feel the jvm running on wasm already? Even the uis would work by rendering via canvas in software ...