[throwaway894345]

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?

[brabel]

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

JVM bytecode is quite approachable: https://en.wikipedia.org/wiki/List_of_Java_bytecode_instruct...

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.

[1] https://blogs.oracle.com/javamagazine/post/creating-a-java-o...

[throwaway894345]

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

[pjmlp]

CLR was designed for C++ as well. About 20 languages supported on release day.

IBM TIMI was designed for C and C++.

Amsterdam Compilers Toolkit was designed for Pascal, Modula-2 and C.

Nothing new really.

[throwaway894345]

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

[pjmlp]

CLR didn't need to be shoved into the browser, it was there already via ActiveX first and Silverlight second.

As for the others since 1950's, plenty of stuff to study there.