I assume there are complexities in compiling C/C++ to the JVM but wouldn't wasm have many of the same issues?
Bytecode has its flaws but the trend is away from using bytecode for all languages and towards partial evaluation of AST interpreters. That works well for managed OO like languages, and also other managed scripting languages, and it can also run C/C++/Rust/FORTRAN etc, with interop between the languages.
WASM has no real roadmap to get to running anything other than small, manually memory managed programs. It's being billed as "generic" but I don't see it. GraalVM is generic. WASM struggles to run anything that requires a more sophisticated runtime than malloc.
You mean small software like AutoCAD? https://web.autocad.com/
> GraalVM is generic.
How well does GraalVM perform on a beefy 200 MHz 32-bit microcontroller with 256 kB RAM? How do you use GraalVM to run existing C++ code on a website?
Or does your definition of "generic" exclude some platforms?
Don't get me wrong, I'm sure GraalVM has its uses in the server side, and perhaps in desktop (or even mobile) application context. It just doesn't seem generic in a way that is useful for embedding small/medium size libraries/executable code on top of systems written in C/C++/Rust.
And for the microcontroller, likewise - why would I want the overhead of a WASM VM on such a device? You won't fit V8 on it. Anyway, Graal can AOT compile programs down to small native binaries, but they're not that small at this time: give it a few megabytes of RAM and then yes it's possible.
Well, not only browser developers. Often the corporate higher ups just suddenly want things like being able to run C++ based product in a web browser. I'd also rather use a native application, but others don't seem to always agree.
> why would I want the overhead of a WASM VM on such a device?
For example for rapid prototyping or as a way to safely provide plugins at runtime on the device without requiring to flash firmware (or more expensive, larger flash chip). Anyways, there'd be no VM (or GC) overhead during execution other than bounds checks, because you can just compile WebAssembly into native in one go.
> You won't fit V8 on it.
Why would you need V8? You'd just need something that can read WebAssembly bytecode, allocate registers and emit platform native assembler. I think direct 1-1 stack machine mapping codegen could be made in few tens of kB. A bit more for basic register allocation.
People are currently working on them. Also 100% performance is not always necessary, getting to 50%ish shouldn't be that hard. That's plenty for a scripting engine replacement scenario, for example. Or for bit banging some GPIOs on a microcontroller.
I think Mozilla's WASM engine is somewhat faster than WASM module in V8. The point is regardless you won't need a Javascript engine in the first place.
> why not just compile straight to native
To be able to run validation checks on the bytecode, so that you can still execute programs that are trusted only to a certain point.
And to support multiple platforms.
There are also a lot of platforms that aren't supported by LLVM or are not first tier targets.
..and that's great. You can implement them properly to fit your language, instead of Rube Goldberg devices around JVM idiosyncrasies. Just as would you do with any HW instruction set.