It seems like wasm will finally enable the "write once, run everywhere" promise that java made but never truly executed by starting with the premise that you don't need "one true language" (java), but rather just the VM.
Yeah, I know the JVM supports several languages these days but most require non-superficial similarities to Java (garbage collected, etc.)
This ignores the tons and tons and tons of work that would really have changed that.
I don't think it really has anything to do with whether you have one true language or not.
There were plenty of well-funded efforts to have "write once, run everywhere" in the past that were just VM's and formats (ANDF, etc).
In practice, a lot of things have changed since Java that have made this kind of approach feasible. As a simple example: good compiler infrastructure to build on top of is much more available than it was then. These days you pretty much just have to write a frontend.
Even though GCC existed then, it was still compiling statement at a time!
Sure, i'm just saying your comment seemed to be saying "java's write-once run everywhere failing was due to trying to have one true language", and i think that part is fairly orthogonal.
I don't believe it's failure is entirely based on it shipping with a prescribed language--but I wouldn't say it's orthogonal. Java, the language, promised "write once, run everywhere" whereas the JVM in the beginning was just an implementation detail. The JVM slowly evolved into a universal vm concept, mostly at the hands of the community and not those (Sun, Oracle) that had the most control over it.
You literally can't write a portable "hello world" command line app in WASM. It's the worst "write once, run everywhere" of anything. Which is expected because it distinctly does not provide any standard APIs or syscalls. There's no standard library. At all.
Someone may attempt to add a batteries-include system that uses WASM with a bunch of platform-abstraction libraries, but WASM itself does not provide that. And isn't going to provide it.
You can make a portable library with WASM, assuming you have zero dependencies on anything, but that's about it.
> but most require non-superficial similarities to Java (garbage collected, etc.)
It should be noted that doing this requires non-superficial similarities to *nix/POSIX (signals, files, threads, etc). It's not like you could run Nginx on this without its POSIX impl or in the browser w/out Emscripten's POSIX impl or on any other WASM runtime w/out a POSIX impl.
Has this been done without jumping through hoops like compiling to a specific CPU target with GCC then doing a binary conversion to JVM bytecode (NestedVM does this via MIPS I believe)?
Depends on what you mean by hoops (ala clang), but there is Graal which can run LLVM bitcode [0] but I am unsure if it can compile it. I have personally compiled C code to WASM and then to the JVM via [1]. C/C++ are complex (and/or have complex optimizations) so a compiler should be used, but doesn't necessarily have to target a specific CPU but still have to have a bit-preference and what not. And of course once you interact with the system, some abstraction has to occur somewhere.
GraavlVM Seems like an incredibly useful tool for sandboxing non-java languages with java/jvm interoperability. LLVM really is enabling a renaissance of language interop. This is fantastic stuff.
Yeah, I know the JVM supports several languages these days but most require non-superficial similarities to Java (garbage collected, etc.)