Those languages are very much designed around the JVM though. You
have Scala, but not eg: C++, because the JVM itself is much higher level than what many languages would want to target.
Arguably, JVM languages have much better tooling for them to be designed and interoperable (through Truffle and GraalVM) than WASM where everyone has to write a backend (or use LLVM which has its downsides).
These are all languages that were designed expressly to run on the JVM, whereas WASM aspires to support existing languages. I'm not familiar with JVM bytecode (and would love to hear from someone who is), but I'm guessing the JVM bytecode offers less in the way of low-level control over memory allocations and so on which would be required to compile C, C++, Rust, Go, etc programs with reasonable performance characteristics?
JVM bytecode assumes the GC allocates and frees memory, so no, you don't have direct access to memory... though the Java standard library does let you allocate bytes and manage those yourself[1], not sure if you would consider that "more control over memory allocations".
And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO.
> though the Java standard library does let you allocate bytes and manage those yourself[1], not sure if you would consider that "more control over memory allocations".
That's interesting. So if you wanted to build a C compiler targeting the JVM, you would just request a big byteslice from the API and implement your own stack + heap on top of it (such that you never actually use the JVM GC)?
> And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO.
It sounds like the fundamental distinction is that WASM will have both manual memory management APIs as well as GC APIs while Java will only have GC APIs.
I'm not really arguing that WASM was the first to target previously existing languages, I'm arguing that WASM has a reason to exist because (1) it's an extant project and (2) it solves for other requirements (e.g., streaming compilation) that weren't previously addressed. I could well be wrong, and if so I'd genuinely like to hear how CLR actually solves all of WASM's requirements (essentially how we should have just shoved CLR into browser engines and called it a day!).