11–20 of 83 posts
WASM is great because we can run it in V8 isolates which are much lighter weight than containers or full VMs.
Earlier quoted context omitted.
You are correct, but this time, all industry leaders cooperate instead of competing: https://webassembly.org/ (see browser support). Also implementation in browsers is different (more "close to the metal" let's say) and the whole web platform has evolved a lot, and that changes a lot of things.
>(more "close to the metal" let's say) I don't think that's really fair to say at all.
Earlier quoted context omitted.
>(more "close to the metal" let's say) I don't think that's really fair to say at all.
I would say that JVM bytecode is significantly higher level than WebAssembly, no?
For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer to its start address? Or an int64 pointer? Maybe you encode it as two int64s? Once you've made a choice, good luck calling functions generated by a compiler that made a different one!
Another problem (in the web context) is blocking--Emscripten runs into this one. You can't suspend WebAssembly execution in the middle of calling out to an imported function. If a WebAssembly program wants to read keypresses interactively, it can't use a blocking function like read(). You have to pass the keypresses in at the outer level--or reimplement the call stack yourself like Go did (https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0...).
In general, WebAssembly code today is very tied to the JavaScript code that manages its interaction with the outside world. You can't just write a WebAssembly program that uses OpenGL. You also need to write the JavaScript that turns those calls into WebGL calls. I don't think this is a fundamental problem--we just haven't seen standards develop yet. As platforms start to define their API directly in terms of WebAssembly, without a JavaScript layer, we may see more of a "standard ABI" develop. Until then, it's hard to know what kind of APIs to target or support as an application or compiler writer.
I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory. For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer…
Sounds like every architecture ever? There’s an architecture specification and then there’s an ABI. It’s common to only support some small number of sizes, x86 is a bit the odd one out these days.
I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory. For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer…
> For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer to its start address? Or an int64 pointer? Maybe you encode it as two int64s? Once you've made a choice, good luck calling functions generated by a compiler that made a different one! Sounds like every architecture ever? There’s an architecture specification and then there…
At the risk of sounding like an old grumpy guy[0], isn't this kind of what Java[0] set out to achieve some 20 years ago? I am in no position to compare the two by any metric other than age. But I am old enough to appreciate how such ideas tend return every couple of decades. Is this an IT thing, or is this phenomenon known in other areas, too? [0] I am not even that old, and I do my best to not be grumpy. [1] Yes, ye…
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 withou…
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.