Maybe I'm misunderstanding, but my thought was he was suggesting that the host/VM could be written in WASM, which could then run any arbitrary thing as Docker does today.

JNI? The JVM doesn't sandbox native code, nor can you target the JVM with (for example) GCC. So what are you referring to?

Why do you need JNI? You could just compile C-like code to run on the JVM using a byte[] array as the equivalent of memory. This is similar to how high-performance Java code is written already, to ensure that GC is completely out of the way.

In fact GCC used to have a JVM target, called GCJ. It was removed due to lack of maintenance.

> You could just compile C-like code

Which also involves rewriting literally everything to Java.

> In fact GCC used to have a JVM target, called GCJ

Which again, had a Java frontend. So, nothing like targeting WASM with C/C++/Rust.

Here have fun, http://nestedvm.ibex.org/

That doesn't work. Java web apps have failed. Nobody uses Java in the browser anymore. So even if we use JVM bytecode as the intermediary language you would need to translate that into ASM.js and then you basically introduced arbitrary complexity for literally no reason and you won't have the performance benefit of webassembly.

The browser engine developers effectively paid a huge up front fixed cost and now anyone can use Webassembly in nodejs which then spills over to more and more use cases like cryptocurrencies using a modified WASM VM for their zk sync layer two solution.

The JVM simply wasn't built for these use cases.

we are talking about server side applications though. I don't think anybody runs docker on the browser!

A generic compilation target to the JVM would have worked, but it wasn't available 15 years ago, and GraalVM is mature about now, but so is WASM.

Docker already have the community, tools and distribution layer. You can think as Wasm as another resource that can be run in Docker as it's today. You continue using the same tools with a new way of packaging and run applications / runtimes.

"and non-JVM apps like PostgreSQL" PostgreSQL can (and has) been compiled to Wasm! It was on HN a couple of months ago https://news.ycombinator.com/item?id=33067962

If this is what is meant, then compile PostgreSQL with CLang and run the resulting LLVM binary with GraalVM on JVM...

...and with GraalVM you can run WASM on JVM...

> JVM+JAR existed

JVM can only run apps written for it: Docker & WASM don't have that limitation.

> it can run non-WASM and non-JVM apps like PostgreSQL, etc...

but WASM can run Postgres

With GraalVM you can run any LLVM binary on JVM...

That is true, graal's certainly more readily comparable.

Source?

Here you have the different links:

- Article: https://supabase.com/blog/postgres-wasm

- Repository: https://github.com/snaplet/postgres-wasm

- HN Thread: https://news.ycombinator.com/item?id=33067962

as well as the sibling linked repo there's also https://www.crunchydata.com/developers/playground

C and C++ compiler for the JVM from 2006, http://nestedvm.ibex.org/

> JVM can only run apps written for it: Docker & WASM don't have that limitation.

Of course it does; WASM is just a format, still need to create the right functions that the runtime will call to do the useful stiff

With GraalVM you can run WASM on JVM...

> JVM can only run apps written for it: Docker & WASM don't have that limitation.

Of course they do. You can only run apps on WASM that have been compiled to WASM bytecode. You can only run apps on Docker that have been compiled to whatever bytecode is supported by the container runtime (which can be x86, ARM, x64, etc.).

> but WASM can run Postgres

WASM can run WASM-compiled Postgres. It has to be specifically compiled for WASM, which also means it generally needs to be ported to WASM first (as WASM runtimes have a lot of limitations that arbitrary C programs probably don't conform to).

JVM can run apps _compiled_ for it. WASM has the _exact same_ limitation.

Someone put in the effort to get Postgres to compile for WASM. That's great :) Maybe someday every application will compile to WASM as the preferred choice over the linux interface.

Compiling apps for different targets is VERY MUCH not a simple, low effort task though. Something like a database that must have an incredible number of optimizations in the way it makes syscalls, will have to a full stream of work to keep each target running well.

It can be done. But if "one of these thigns is not like the other" with your three things- Docker is the odd duck out.

You can compile any C / C++ app down to wasm. In fact that’s the raison d’être of the technology: to provide a portable safe way to run binaries. Here is a link to Postgres in wasm for instance: https://supabase.com/blog/postgres-wasm. The way it works is that instead of outputting assembly for a given architecture in the backend compiler, it outputs wasm instructions that are designed to map all architectures, not like the jvm which is designed primarily for Java in the front end.

That's not entirely true. C/C++ code can certainly be compiled down to WASM, but you cannot interface with the operating system as you would in a normal C/C++ program. To get around that restriction postgres-wasm ships an entire Linux distribution that is run inside the browser. This comes with an immense performance penalty.

To get an impression of the performance penalty, just run the following query:

  SELECT SUM(i) FROM generate_series(0, 1000000, 1) tbl(i);

This simple query completes in 100ms locally on my laptop, but takes 17265ms in postgres-wasm. That is a slowdown of 170x.

Now that is not WASM's fault - when running the same query in duckdb-wasm [1] on my laptop the query takes 10ms using WASM, and 5ms when run locally, with a slow-down of only a factor of 2. But in order to achieve those results we did have to adopt the DuckDB codebase to compile natively to WASM. That is absolutely possible but it does take engineering effort - particularly when it comes to larger older projects that are not designed from the ground up with this in mind.

[1] https://shell.duckdb.org

Thank you for these details. Always suspected these claims but hadn’t dug deep enough.

Seems like some X can now run in wasm should come with disclaimer (includes Linux)

Here, have your C and C++ compiler for JVM bytecode from 2006.

http://nestedvm.ibex.org/

But don’t I have to compile all my dependencies too? This seems like a lot to ask, but maybe it’s common in some domains.

> You can compile any C / C++ app down to wasm.

This is incorrect, there is a long list of limitations that your C/C++ code must conform to in order to compile to WASM. There's a whole section dedicated to this in the Emscripten docs: https://emscripten.org/docs/porting/index.html.

The chances your existing C/C++ app will compile to WASM and run correctly are much smaller than with Docker.

> not like the jvm which is designed primarily for Java in the front end

This is also wrong, JVM bytecode is explicitly designed to be polylingual and is the compilation target for many non-Java languages like Scala, Kotlin, and Clojure. WASM being a compilation target is not what makes it unique from the JVM.

Ironically you actually can run LLVM bitcode on the JVM these days, including inside an optional sandbox. It can run "anything" in the unsandboxed mode (as long as it can compile with LLVM), because it allows native calls out to the OS. So the universal [J]VM vision has actually happened, it's just nobody really knows about it.

LLVM bitcode isn't all that portable though, and of course, the binary will still be OS specific because C/C++ code relies on native APIs. The primary reason to do this is so the Graal JIT compiler can optimize native code and higher level dynamic script/bytecode together and remove interop overhead.

However, you can theoretically run whole programs this way inside the Graal sandbox. If you do that you get an emulation of POSIX that is reimplemented on top of the Java standard library, so the code becomes portable, and in managed mode there's an additional party trick - the native C/C++ malloc is replaced with garbage collected allocations and memory accesses are bounds checked. So code run this way gets all the memory safety errors blocked automatically. This upgrade comes with two costs though, one is slower execution/more memory usage, and the other is you have to buy GraalVM EE. The community edition can run bitcode, but not in the sandboxed/managed mode.

Oh and GraalVM can also run WASM. So you can have cake and eat it, everything running together via their 'polyglot' interop system.

how does pthread_create compile down?

In Emscripten that uses a pthread implementation layer built on top of Web Workers + a shared wasm Memory. Basically memory is shared, and you have atomic instructions, and each thread of execution gets its own Web Worker.

That has some limitations, but for the most part it works just like you would expect pthreads to.

what's the non-most part that differs?

The main thread is a little special on the Web since it can't block, which can cause issues (like pthread_create doesn't immediately create an available pthread). There are workarounds for most of those issues (like pre-allocating a threadpool), and many applications work well, but sometimes not out of the box. See

https://emscripten.org/docs/porting/pthreads.html#special-co...

thank you