Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Interface Types: Interoperate with All the Things

hacks.mozilla.org

Post reply on HN
Print view View original

81–90 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#81

Post by chrisseaton »

Rusky wrote: post #80
chrisseaton wrote: post #79

Earlier quoted context omitted.

> Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs It does - LLVM bitcode.

LLVM bitcode is far worse than WASM bytecode as a standard binary interchange format. It is intentionally non-portable and unstable by its designers. Google tried using it for this purpose with PNaCl and it wasn't great. Apple makes it work by strictly controlling the target hardware they use it for, and with massive investment in the toolchain.

I didn't claim it was a good binary format - I just claimed GraalVM supports it, which it does.

Re: WebAssembly Interface Types: Interoperate with All the Things

#82

Post by mrec »

TeMPOraL wrote: post #73
pjmlp wrote: post #55

Earlier quoted context omitted.

Many designers and game devs see it otherwise.

Gamedev is a separate topic. As for designers, they are on the opposite side from users in the tug-of-war of control over content rendering. I don't believe they should get 100% of their way.

Gamedev falls squarely into my "smallish subset of use cases". It does legitimately need non-DOM UI, but it's not a huge part of the Web (yet).

As for designers, thank you for finding a much more diplomatic phrasing than the one I was about to write.

Re: WebAssembly Interface Types: Interoperate with All the Things

#83

Post by nerdponx »

mrec wrote: post #66
nerdponx wrote: post #56

Earlier quoted context omitted.

This probably a good subject for a separate thread, but I do wonder why JVM-in-browser failed so hard. I know there were "security issues" but surely those weren't any worse than the JS security issues we have today?

Steve Klabnik wrote a blog post around this last year. More challenging the "isn't WASM just another Java?" take, but I think still relevant to your question. https://words.steveklabnik.com/is-webassembly-the-return-of-...

That immediately clarifies the difference. Thank you.

Re: WebAssembly Interface Types: Interoperate with All the Things

#84

Post by wahern »

bcheung wrote: post #76
guhidalg wrote: post #70

Earlier quoted context omitted.

Yes but like the parent poster said, all of the CLR features are really to serve one language: C#. All other languages primarily targeting the CLR must be understood in the context of “how would you express this thing in C# and how will a C# client interact with your assembly”. Thus, WASM will forever be tied to javascript and all other languages will need to deal with questions of “how would I express this in JavaSc…

C# is the largest language for sure but it was designed for multiple languages from the start. There are things you can do in CIL and other languages that you can't do in C# even. Functional languages and pattern matching can be expressed quite well in .NET which aren't in C# (at least not yet fully). I think the statement that the CLR ties you to C# is not justified. Can you elaborate why you think this is the case?…

WASM is tied to existing JavaScript engines and their constraints. For example, WASM doesn't support more efficient control flow because of the design of V8 (and possibly SpiderMonkey):

http://troubles.md/posts/why-do-we-need-the-relooper-algorit...

https://news.ycombinator.com/item?id=19997091

Re: WebAssembly Interface Types: Interoperate with All the Things

#85

Post by mkl »

> Document.createElement() takes a string. But when I call it, I’m going to pass you two integers. Use these to create a DOMString from data in my linear memory. Use the first integer as the starting address of the string and the second as the length.

This seems like its introducing buffer overflow vulnerabilities, if the code can be tricked into using the wrong numbers. Sure, just into WebAssembly memory, but if everything's implemented in WebAssembly, won't there often be sensitive information in there?

Doing some more research, it seems like this may be a common problem: https://stackoverflow.com/questions/41353389/how-can-i-retur...

Re: WebAssembly Interface Types: Interoperate with All the Things

#86

Post by CUViper »

mkl wrote: post #85

> Document.createElement() takes a string. But when I call it, I’m going to pass you two integers. Use these to create a DOMString from data in my linear memory. Use the first integer as the starting address of the string and the second as the length. This seems like its introducing buffer overflow vulnerabilities, if the code can be tricked into using the wrong numbers. Sure, just into WebAssembly memory, but if eve…

Doesn't each wasm module get its own isolated memory? If so, then you could only shoot your own sensitive foot.

Re: WebAssembly Interface Types: Interoperate with All the Things

#87

Post by yellowapple »

pjmlp wrote: post #52
Rusky wrote: post #35

Earlier quoted context omitted.

You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.

Please, what wonderful feature does WASM have that neither JVM nor CLR are capable of? Or for that matter, the myriad of bytecode formats devised since UNCOL, like the IBM and UNISYS's language environments on their mainframes.

WASM is much smaller and simpler than either. This makes it easier to implement, both within browsers (as evidenced by most mainstream browsers already supporting it natively, and the rest via a polyfill) and beyond (e.g. the myriad of WASM runtimes out there - both interpreted and JIT/AOT compiled - written in all sorts of languages and usable outside a web browser). Same goes for most other bytecode VMs of a similar style/vintage (Dis, Parrot, BEAM, Dalvik, etc.).

Can't speak to mainframe VMs, since I ain't familiar with them. It's reasonable to assume they were proprietary, though (that's how things typically were back in those days), so WASM has a leg up there.

Re: WebAssembly Interface Types: Interoperate with All the Things

#88

Post by yellowapple »

CUViper wrote: post #86
mkl wrote: post #85

> Document.createElement() takes a string. But when I call it, I’m going to pass you two integers. Use these to create a DOMString from data in my linear memory. Use the first integer as the starting address of the string and the second as the length. This seems like its introducing buffer overflow vulnerabilities, if the code can be tricked into using the wrong numbers. Sure, just into WebAssembly memory, but if eve…

Doesn't each wasm module get its own isolated memory? If so, then you could only shoot your own sensitive foot.

There's no guarantee that the module's memory is strictly isolated; I don't recall what the specification says, but on a technical level there's nothing stopping a WASM implementation from exposing the same memory range to multiple WASM modules (and in fact, I can imagine this to be a very common use case for multiple memories, e.g. defining STDOUT and STDIN as memories shared with other modules, with one module reading and the other writing).

Most (all?) WASM runtimes currently enforce this isolation, though, for security reasons. If any do allow memories to be shared between modules, I'd imagine it'd be very explicit and opt-in.

Re: WebAssembly Interface Types: Interoperate with All the Things

#89

Post by [deleted] »

mrec wrote: post #38
pjmlp wrote: post #28

Earlier quoted context omitted.

DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/

For a smallish subset of use cases, maybe. But replacing the DOM with a canvas-based UI for general use would be reinventing many of the problems of Flash.

[deleted]

Re: WebAssembly Interface Types: Interoperate with All the Things

#90

Post by bcheung »

wahern wrote: post #84
bcheung wrote: post #76

Earlier quoted context omitted.

C# is the largest language for sure but it was designed for multiple languages from the start. There are things you can do in CIL and other languages that you can't do in C# even. Functional languages and pattern matching can be expressed quite well in .NET which aren't in C# (at least not yet fully). I think the statement that the CLR ties you to C# is not justified. Can you elaborate why you think this is the case?…

WASM is tied to existing JavaScript engines and their constraints. For example, WASM doesn't support more efficient control flow because of the design of V8 (and possibly SpiderMonkey): http://troubles.md/posts/why-do-we-need-the-relooper-algorit... https://news.ycombinator.com/item?id=19997091

Tied to the engine is orthogonal to tied to the language. You can compile C, C++, and Rust to WebAssembly. But you still can't compile JS to WebAssembly.

Given the large amount of code in JS and the number of JS developers, not being able to support a major general purpose language rules out WASM as a cross platform target in my book.

Post reply on HN