Hacker News Reader

Comment by Rusky | Hacker News Reader

The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. WebAssembly does.

This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages.

The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or more feasible to deploy in more scenarios, even without subsetting things the way mobile/embedded Java does.

View on HN

> The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust.

You can run all those languages on top of the JVM!

The JVM also runs many other languages which weren't designed for it, like Ruby and Python.

> You can run all those languages on top of the JVM!

Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.

For example Sulong runs C, C++, Rust https://llvm.org/devmtg/2016-01/slides/Sulong.pdf.

I use it to run unmodified C extensions for the Ruby programming language on top of the JVM.

Truffle C is another example https://www.manuelrigger.at/downloads/trufflec_thesis.pdf.

Thanks to GraalVM. Well, that wasn't always the case and it prompted the need for WASM.

Webassembly came from asm.js, which came from Emscripten. These 3 are a lineage of the same c compilation model targeting a JS Uint8Array as the c heap. Emscripten was published a long time ago, probably 10 years? So, JVM has byte arrays too...

True, I forgot about Graal. IIUC though that's somewhat different from what WebAssembly has done- Graal doesn't define any sort of stable compiler target for C, or produce JVM bytecode from C, but instead (via Truffle) JITs C source or LLVM IR via partial evaluation, right?

That would suggest (again IIUC) Graal/Truffle as a mechanism for using the JVM as a WebAssembly runtime. The WebAssembly format and its associated environment/binding system are a portable way to encode C binaries, with significant benefits over JVM bytecode- that's probably the comparison I should have made.

No that's right, the stable compiler target is someone else's job.

But I wasn't comparing to WebAssembly, so you'll need to argue that point with someone else.

You could build a WebAssembly interpreter on Truffle, yes. I'm not sure anyone's tried it yet so that project is available.

Python, Ruby and Common Lisp were designed for the JVM?

To the extent that their object and memory models match the JVM's, you might say they were. To the extent that they don't, their JVM implementations wind up with warts and inconsistencies.

(But this is pedantry, you clearly know what I meant.)

No, I did not know what you meant. There is a difference between guessing and knowing.

Reply on news.ycombinator.com