4 ms·

It's an open standardized bytecode that's specifically designed to be easy to implement, which means there are already a lot of different runtimes that implemen

It's an open standardized bytecode that's specifically designed to be easy to implement, which means there are already a lot of different runtimes that implement it, so you're not required to have for example JRE or a .NET runtime installed. Because of this simplicity it is also an easy target to compile to, which means that many languages can already be compiled to it.

Alupis 3y ago
> so you're not required to have for example JRE or a .NET runtime installed These days you are not required to have a JRE or .NET runtime installed. At least on the JRE side, it can be embedded in the executable - I assume .NET has something similar. There has to be more to it than that, though. Perhaps it is the "easy" part you mentioned - I have no idea what's involved in building a greenfield java bytecode interpreter, for example.
- secondcoming 3y ago
  Java’s bytecode is extremely simple. You could implement a PoC interpreter in a day if you put your mind to it
  - Alupis 3y ago
    Interesting, and good to know. I guess that brings me back to my original question - why WASM vs. some existing bytecode interpreter? What makes WASM the best choice, and why does it exist?
    - SideburnsOfDoom 3y ago
      WASM is "some existing bytecode interpreter". It's widely deployed, i.e. it's in all major browsers already, and has been for a few years now. That alone makes it a good compilation target.
      - Alupis 3y ago
        It wasn't when WASM was invented, though. That was the question - why make something new when existing bytecode systems would have been made to work and achieve the same goal.
        preseinger 3y ago
        wasm has properties that are unique versus other existing bytecode systems those properties are important
        SideburnsOfDoom 3y ago
        I think that this is a silly question. "Could have been made to work" is far cry from "best choice". Browser vendors agreed that they could standardise something lower level than JavaScript, in the browser, and is is the chosen outcome. Why _not_ make something new? There is experience doing it, so it's possible, is a known engineering task, and it can be built to the specific requirements. And by making a new one, you don't have to buy into someone else's brand or ecosystem. The rest is historical details. Ultimately, asking strangers on the internet to justify software architecture design decisions that happened years ago and worked out rather well, is for the birds. In future the question is going to be less "why use WASM when JVM is right there, one install away", and more "why use JVM when WASM is right there, zero installs away" .
mike_hearn 3y ago
Of course you're required to have a WASM runtime to run WASM bytecode. How else could it run? It's no different to a JVM or .NET in that regard. JVM bytecode is open, standardized and quite easy to implement. CLR bytecode likewise albeit less easy to implement. You can implement a simple JVM on your own. Avian is an example of a lightweight JVM written by two guys (albeit very productive guys) and that didn't only implement the spec but had a proper JIT compiler, AOT compiler and semi-decent garbage collector too! In practice, ease of implementation isn't very important for this sort of thing. Having a good open source implementation is sufficient. WASM has this in V8 and other than the rewrite-it-in-rust factor it's not super clear (to me?) what other runtimes bring to the table? > Because of this simplicity it is also an easy target to compile to No, this is backwards. WASM's simplicity makes it harder to compile to, not easier, because language implementations have to do more themselves. That's why even after many years the only languages people are using with it are languages with very minimal demands on the runtime, like C or Rust. Languages with more advanced compilation requirements like GC integration (modern GC algos affect the compiler too) have been ignoring WASM so far, and this is why V8's JavaScript engine isn't itself running on WASM.

Alupis 3y ago

> so you're not required to have for example JRE or a .NET runtime installed These days you are not required to have a JRE or .NET runtime installed. At least on the JRE side, it can be embedded in the executable - I assume .NET has something similar. There has to be more to it than that, though. Perhaps it is the "easy" part you mentioned - I have no idea what's involved in building a greenfield java bytecode interpreter, for example.

secondcoming 3y ago
Java’s bytecode is extremely simple. You could implement a PoC interpreter in a day if you put your mind to it
- Alupis 3y ago
  Interesting, and good to know. I guess that brings me back to my original question - why WASM vs. some existing bytecode interpreter? What makes WASM the best choice, and why does it exist?
  - SideburnsOfDoom 3y ago
    WASM is "some existing bytecode interpreter". It's widely deployed, i.e. it's in all major browsers already, and has been for a few years now. That alone makes it a good compilation target.
    - Alupis 3y ago
      It wasn't when WASM was invented, though. That was the question - why make something new when existing bytecode systems would have been made to work and achieve the same goal.
      - preseinger 3y ago
        wasm has properties that are unique versus other existing bytecode systems those properties are important
      - SideburnsOfDoom 3y ago
        I think that this is a silly question. "Could have been made to work" is far cry from "best choice". Browser vendors agreed that they could standardise something lower level than JavaScript, in the browser, and is is the chosen outcome. Why _not_ make something new? There is experience doing it, so it's possible, is a known engineering task, and it can be built to the specific requirements. And by making a new one, you don't have to buy into someone else's brand or ecosystem. The rest is historical details. Ultimately, asking strangers on the internet to justify software architecture design decisions that happened years ago and worked out rather well, is for the birds. In future the question is going to be less "why use WASM when JVM is right there, one install away", and more "why use JVM when WASM is right there, zero installs away" .

mike_hearn 3y ago

Of course you're required to have a WASM runtime to run WASM bytecode. How else could it run? It's no different to a JVM or .NET in that regard. JVM bytecode is open, standardized and quite easy to implement. CLR bytecode likewise albeit less easy to implement. You can implement a simple JVM on your own. Avian is an example of a lightweight JVM written by two guys (albeit very productive guys) and that didn't only implement the spec but had a proper JIT compiler, AOT compiler and semi-decent garbage collector too! In practice, ease of implementation isn't very important for this sort of thing. Having a good open source implementation is sufficient. WASM has this in V8 and other than the rewrite-it-in-rust factor it's not super clear (to me?) what other runtimes bring to the table? > Because of this simplicity it is also an easy target to compile to No, this is backwards. WASM's simplicity makes it harder to compile to, not easier, because language implementations have to do more themselves. That's why even after many years the only languages people are using with it are languages with very minimal demands on the runtime, like C or Rust. Languages with more advanced compilation requirements like GC integration (modern GC algos affect the compiler too) have been ignoring WASM so far, and this is why V8's JavaScript engine isn't itself running on WASM.