Hacker News Reader

Comment by white-flame | Hacker News Reader

Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably.

Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level, so even runtime language VMs can run in such a model without harsh slowdowns. While this literally offers fewer features than the JVM, it doesn't restrict which features the final runtime can implement.

This of course is all based on the assumption that you have a CPU-level environment that already bootstraps what you need (like C-based garbage collectors running underneath your dynamic language); or that you're running low-level, assembly-style code for speed reasons.

View on HN

Unfortunately, as a side effect of it supporting only one memory model, it means that the host code only has a giant memory bag to work with, meaning it needs to reconstruct objects from a giant heap. Currently, anything involving more complex host interaction (say, handles to kernel objects like files) is punted on to either the host-bindings proposal (which has a number of issues and basically was agreed was not a way forward) or the GC proposal (which has even more issues).

The current plan for the GC proposal is to allow skipping having memory heaps at all and talk about things in terms of an object graph and types. See comments here: https://github.com/WebAssembly/gc/issues/32

The important part of a runtime to me is the object model, and wasm basically punted on one for now.

Thanks for this comment! Very informative, and not something I would have found otherwise.

Yes, that's what a CPU-level model with byte-level access means, and is how all code running on your computer has its basis. Whatever high level constructs you want are built on top of your asm-level runtime. This is as-designed, as is the only reasonable way to allow different language paradigms to run on top of it. It's also heavily implied by the name.

It does have a notion of function imports & exports, so in the same way it allows you to do what you want, without specifying what you're going to do. For untrusted code, like in a browser, the environment can choose only to extend limited access. For trusted code, the environment can give access to more OS-level functionality. By webasm not specifying what functions to bind, but giving the ability to bind functions, it remains flexible and appropriate for wildly varying deployments.

A generic object model will be a poor fit for many languages. I hope they keep it simple and low level and don't build in an object model. I'd rather have low level features that let you implement your own GC than a built-in object model. If you have zero cost exceptions and multiple function entry points you can implement your own GC, and coroutines and various other constructs without any more overhead than if you were compiling directly to machine code.

Basically, zero cost exceptions let you unwind and capture the stack while not slowing down the common case, and multiple entry points let you build the stack back up without compiling a large amount of duplicate code. This gives you arbitrary stack manipulation without explicit stack manipulation support in the VM. It enables features that usually require special VM features, such as GC, coroutines, lightweight threads, (delimited) continuations, effect handlers, C# style async.

> Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably.

> Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level [...]

The only real difference between the JVM and WASM is that the JVM came from the academic world of "stack-based VMs are better" while WASM comes from the world of "register-based VMs are better".

Both have the same limitations that all the other VMs have. And languages are equally difficult to port to either of them.

What WASM has (and the JVM always lacked) is a compatible zero-friction VM installed on more or less every computer of this planet.

This is the _"everywhere"_ that Java and the JVM wanted but never had.

Wasm is stack based too. The way data flow is encoded is not so important. A compiler can easily generate code for either a stack machine or a register machine. The VM will decode that into SSA again, so it only matters insofar as the representation has to be compact and fast to decode.

The main difference is that the JVM has a garbage collected heap and high level instructions for OOP, whereas wasm is lower level than C and only slightly higher level than assembly. Instead of an object model with GC you have raw pointers.

Basically mainframes execution environments.

Reply on news.ycombinator.com