4 ms·
Java’s bytecode is extremely simple. You could implement a PoC interpreter in a day if you put your mind to it
by 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 agoInteresting, 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 agoWASM 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 agoIt 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 agowasm has properties that are unique versus other existing bytecode systems those properties are important
- SideburnsOfDoom 3y agoI 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" .