An Abridged Cartoon Introduction To WebAssembly • Hacker News Board

Re: An Abridged Cartoon Introduction To WebAssembly

#61

Post by white-flame » Mon, May 15, 2017, 7:27 PM UTC

pfooti wrote: post #58

vivin wrote: post #26

> For now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Does this worry anyone else? Or I am getting worked up over nothing?

Yeah, it's of moderate concern. I can see why it's not really a priority here, since they're probably targeting languages that already don't have GC to compile into WASM, like c++ as a canonical example. I have to imagine that GC is also a pretty huge section of performance / JIT compilation problems in the javascript runtime. So shipping a spec that doesn't support it is no worse than allowing statically compiled co…

The addressable memory space doesn't include code, globals, stack, etc, but only that memory which could be considered the heap.

Pointers into memory are 32bit base + 32bit offset, non-wrapping, so 33-bit distances from a base pointer. Each memory access needs a check to that (relatively non-changing) pointer. Memory spaces can request expansion in multiples of 64KB, and can have configured maximum sizes. This leaves it all compatible with using the MMU to trap accesses beyond allowed memory. The example from the paper linked elsewhere is that on a 64 bit machine, you can allocate 8GB of virtual address space, which covers the entire possible addressable range of wasm instructions, and use permissions to trap out of boundness. The very notion of allocating that 8GB already encapsulates memory sandboxing, as long as the addressability limits of instructions can't be usurped (and it's formally been shown to be sound).

Re: An Abridged Cartoon Introduction To WebAssembly

#62

Post by white-flame » Mon, May 15, 2017, 7:30 PM UTC

tamat wrote: post #39

after reading many tutorials about WASM I still figured out one of the most important questions for me: Would I be able to call JS functions from WASM? or pass callbacks to WASM. Because WASM sounds like it goes agains the async nature of JS and I have the feeling that is going to be very annoying to merge both worlds. Also if I cannot call any JS func from WASM it means I cannot call WebGL or Audio so I dont know wh…

Wasm has explicitly declared imports & exports, so that it can be called from, and call into, both JS and other wasm modules. I haven't seen anything regarding dynamic linking, but just linking these declarations at wasm module start time.

The interface should take care of all type conversion between wasm and JS primitive types (notably varying integer sizes and JS floats). wasm's 64-bit integers will likely not be allowed across a JSwasm interface.

Re: An Abridged Cartoon Introduction To WebAssembly

#63

Post by petters » Mon, May 15, 2017, 7:58 PM UTC

amelius wrote: post #3

Since JS is already quite fast nowadays, how much faster will WASM typically be? (Yes, I know, it depends. I'm just looking for a rough estimate.)

I am running an integer programming solver in the browser with wasm: https://www.strandmark.net/wasm/glpk.html

Its single-threaded performance is essentially native, but I don't have the numbers.

Re: An Abridged Cartoon Introduction To WebAssembly

#64

Post by throwasehasdwi » Mon, May 15, 2017, 7:59 PM UTC

rustyhacker wrote: post #43

throwasehasdwi wrote: post #18

Earlier quoted context omitted.

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

I'm not entirely convinced that the reason why people aren't using their preferred language is due to the absence of WASM up until now. Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web. I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and second…

You might be right about C++/Rust but I hear constant complaints from C#, Java, and Go devs about JS. It feels like about half of them would jump ship immediately given another choice. The truth is that even with all the advancements JS has made the tooling and features are still years behind some other mainstream languages.

The transpilers don't work that great and don't produce standard bytecode, in this regard WASM will be a game changer.

Re: An Abridged Cartoon Introduction To WebAssembly

#65

Post by Skuzzzy » Mon, May 15, 2017, 8:00 PM UTC

ericfrederich wrote: post #55

Currently browsers only support JS. If you want another language you have to transpile to JS or implement your language in JS, etc. If the browser vendors were going to add another language I would have hoped it would be something so generic like LLVM instead of this WebASM which is too tied to JS.

Llvm has a web assembly backend

Re: An Abridged Cartoon Introduction To WebAssembly

#66

Post by Canada » Mon, May 15, 2017, 8:03 PM UTC

amyjess wrote: post #50

thaumasiotes wrote: post #29

Earlier quoted context omitted.

Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?

Conceptually? It's not that different, and the only problems with Java were its implementation. * Java was plagued with security problems. One area where Java really shot itself in the foot was that unsigned applets were sandboxed, but signed applets had unfettered access to everything, so you had to choose between signing and sandboxing. And then once security concerns became a big thing, Sun responded by killing su…

> you could just turn plugins off or install an extension to force you to click to load Flash content. You can't do that with JavaScript, so maybe WASM will bring that part of the old days back too.

NoScript?

Re: An Abridged Cartoon Introduction To WebAssembly

#67

Post by throwasehasdwi » Mon, May 15, 2017, 8:05 PM UTC

copperx wrote: post #25

throwasehasdwi wrote: post #18

Earlier quoted context omitted.

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

I agree, but at the same time I look at the Webassembly web page, and they explicitly state that replacing Javascript is not their objective. Why is that?

It's not the overall objective but that's exactly the objective of a lot of people rooting for it. Think of how many people would be pissed off if they said "we're gonna try to replace javascript". Google did that with Dart and everyone gave them the finger... sunk cost fallacy.

Better to develop something for "performance" that just happens to be able to replace JS as a side benefit. Makes it a lot easier to swallow

Re: An Abridged Cartoon Introduction To WebAssembly

#68

Post by throwasehasdwi » Mon, May 15, 2017, 8:06 PM UTC

thaumasiotes wrote: post #29

throwasehasdwi wrote: post #18

Earlier quoted context omitted.

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?

Java applets were far too ahead of their time. Now that we actually have the bandwidth and computing power to support Applets they would be far superior than the Frankenstein of CSS, JS, and HTML we have now.

Re: An Abridged Cartoon Introduction To WebAssembly

#69

Post by moosingin3space » Mon, May 15, 2017, 8:07 PM UTC

throwasehasdwi wrote: post #18

gavinpc wrote: post #14

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it. The other side of that, then, is the great potential for interop that Javascript offers. We now have a wo…

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

I'm very interested in the possibility of using a WASM VM as a unit of process isolation in an operating system. I actually kind of like Babel-compiled JavaScript, so I'm not as interested in WASM as a way to "get away from JavaScript", but the VM-based containerization possibilities (maybe with hardware-assist) are very cool.

Looks like Docker/Unikernel Systems actually has plans to build something like this: https://github.com/linuxkit/linuxkit/tree/master/projects/mi...

Re: An Abridged Cartoon Introduction To WebAssembly

#70

Post by thaumasiotes » Mon, May 15, 2017, 8:21 PM UTC

amyjess wrote: post #50

thaumasiotes wrote: post #29

Earlier quoted context omitted.

Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?

Conceptually? It's not that different, and the only problems with Java were its implementation. * Java was plagued with security problems. One area where Java really shot itself in the foot was that unsigned applets were sandboxed, but signed applets had unfettered access to everything, so you had to choose between signing and sandboxing. And then once security concerns became a big thing, Sun responded by killing su…

I feel reasonably confident in predicting that WASM will have security holes and performance issues too. Computational demand always expands to fill the available performance.

Was there any point in the development of WASM where it made more sense to develop WASM to replace the JVM than it would have made to try fixing the problems with the JVM? Are we at that point now? It sounds like the last two problems fixed themselves.