I think it would be neat if WebAssembly were embedded in other languages, like it is in JavaScript now. For example, suppose Python had a WebAssembly engine. I bet that could replace a lot of C extensions, and it would be as portable/universal as pure Python code, so no need for C compilers, OS-specific binary packages, etc.
WebAssembly is more than the web
41–50 of 83 posts
Re: WebAssembly is more than the web
#42I'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…
It will take a decade to figure that out. Till then, wasm is good for single apps but not an ecosystem
Re: WebAssembly is more than the web
#43Earlier quoted context omitted.
I would say a big difference here is that WASM is designed from the ground up for sandboxing, rather than it being added in after the fact like applets.
While Java has its failings, sandboxing was not an afterthought. Java was designed from day one to be secure-able - with pointer safety, array index safety, the SecurityManager object, classloader security rules, signed applets, etc. (Whether Java actually achieved the security it claimed is a different discussion.)
Re: WebAssembly is more than the web
#44This is technically web, but not in the way you might think. We (Cloudflare) are working on providing WASM support in our Workers [1] product that lets you run code in our 155 data centers around the world. WASM is great because we can run it in V8 isolates which are much lighter weight than containers or full VMs. [1] https://cloudflareworkers.com
i.e. the Chrome team, post-Spectre, are assuming that any value in a process' memory is readable by any code executing within that process.
Re: WebAssembly is more than the web
#45Earlier quoted context omitted.
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…
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…
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.
Re: WebAssembly is more than the web
#46Earlier quoted context omitted.
> 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…
Sure, but there's no standard ABI for WebAssembly yet. I'm basically just saying we need an ABI before we can target it as a platform apart from the web.
Re: WebAssembly is more than the web
#47At 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…
Bytecode formats for application executables delivery was and still is a common practice in the mainframe world.
Xerox PARC workstation, UCSD Pascal systems, IBM and Unisys mainframes as examples.
Re: WebAssembly is more than the web
#48At 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…
Re: WebAssembly is more than the web
#49I think it would be neat if WebAssembly were embedded in other languages, like it is in JavaScript now. For example, suppose Python had a WebAssembly engine. I bet that could replace a lot of C extensions, and it would be as portable/universal as pure Python code, so no need for C compilers, OS-specific binary packages, etc.
Re: WebAssembly is more than the web
#50One thing I am concerned about is startup performance. On my (slow) Chromebook, some of my multi-megabyte WASM files take 10 seconds to compile. Seems we need either faster CPU cores, faster code generation, or some kind of staged JIT compile -- though I guess the latter could be accomplished today with sufficiently clever tooling.