Live data from Hacker News

WebAssembly is more than the web

words.steveklabnik.com

41–50 of 83 posts

Re: WebAssembly is more than the web

#41

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.

You'll never be as fast as compiled, unless you're thinking this engine would JIT at which point your "no need for C compilers" became "carry around a WASM compiler". The more rational approach might be to transpile into the target lang, but there are two primary reasons for C extensions, performance and/or FFI, and neither is accomplished via the transpile route. If it's the third, less oft-cited reason for C extensions, avoiding rewrite and/or reuse existing C code, then yes it has value.

Re: WebAssembly is more than the web

#42
post #15

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…

I share that view. Currently each high level language compiles to its own thing creating huge islands of code. C#, Java, Go, Rust, C etc will all compile their frameworks into the wasm files with very simple facade interfaces. The overhead will be enormous. Also the core is abstraction like memory and thread management is far from here.

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

#43
post #21

Earlier 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.)

That's the thing though. Java's "safety" began and ended as a bullet point in a powerpoint presentation. Not for not trying, but because the API surface is so big and the VM so abstract that they made it impossible for themselves to actually deliver sandbox-level security. To compare, js is tiny, has had thousands of man-years poured into it's security, and its customers prioritize security above everything else, and there are still exploits found in every engine every year. Java's security surface area is enormous in comparison, it has a fraction of the man hours dedicated to sandboxing it, and many of it's customers don't even care if the sandboxing is airtight. You can read through the full webassembly spec in a couple hours.

Re: WebAssembly is more than the web

#44

This 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

What are the security implications here?

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

#45
post #20

Earlier 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…

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.

Re: WebAssembly is more than the web

#46
post #19

Earlier 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.

It's not really a standalone platform, though. It's a sandbox utility to contain high-speed or highly customized computation, that can be plugged into any other platform. By design, it doesn't seem intended to be limited to a single higher-level (well, higher than assembly language) ABI.

Re: WebAssembly is more than the web

#47
post #2

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…

No, Java wasn't the first.

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

#48
post #2

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…

Basically mainframes execution environments.

Re: WebAssembly is more than the web

#49

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.

While this would supplant "C for speed" libraries, it wouldn't supplant "C for OS access" libraries. At some point, system code needs to call the OS.

Re: WebAssembly is more than the web

#50
post #35

One 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.

Chrome Canary contains Liftoff, which is about 8x faster on my machine for initial compilation of wasm. I'm assuming it'll be in Chrome 69.
Post reply on HN