[NortySpock]

To summarize the talk for those in a hurry: the presenter, pretending to be from the future, describes YavaScript as an archaic computer language that served as a bootstrap to WASM, which is now the default compilation target for nearly all languages.

[saghm]

A slight nit: he doesn't actually refer to WASM, but a precursor called asm.js (https://en.wikipedia.org/wiki/Asm.js). WebAssembly wasn't actually announced until 2015 (https://en.wikipedia.org/wiki/WebAssembly)

[jfmc]

WASM is an extremely useful compilation target because of its portability (specially for running on browsers), but it is far from being the "default compilation target" for almost any language. The promised near-native speed is not here (in general you get x2 or x3 slower code but it can be even worse), it is limited to 32-bits (MEMORY64 is on the way but there is not a clear roadmap of when this will be generally available in browsers), blocking IO is a pain, and its design seems to be constrained by the underlying JS JIT (it still looks like ASM.JS with a different syntax).

I still believe that it is a miracle that we have WASM as a standard, and that it runs smoothly across different browser vendors, but why nobody seems to be worried about lack of progress in performance?

LLVM IR would be a much better binary target. It was used in the abandoned PNaCL project. AFAIK Apple uses it (bitcode) to store apps that are later compiled for specific platforms. WASM looks like a toy compared with this technology.

[krasin]

> It was used in the abandoned PNaCL project.

I worked on PNaCl back in 2011. There was a growing understanding that choosing LLVM IR as the representation was a mistake. I even tried to come up with something better, but failed to do so. I was glad to see asm.js and then WebAssembly coming to the scene. In my opinion, WebAssembly is better than what PNaCl could have ever become.

update: and then there was a famous post, "LLVM IR is a compiler IR": https://groups.google.com/g/llvm-dev/c/N3r_a1Vbrog/m/8lukw1x...

[remexre]

The problem is that LLVM IR makes breaking changes fairly frequently -- for instance, LLVM 15 made all pointers untyped; where before you'd have a type like *i32, now you just have ptr.

If you're trying to run the same IR on 32-bit and 64-bit devices, I'd expect you'd need to freeze the word size anyway -- if a C or C++ program uses sizeof(), what value gets returned?

Blocking IO doesn't get solved by switching to LLVM either; you can't block in browser WASM because it'd block the JS thread; a WASM engine not attached to a browser has no such issues. (I wish at least one-shot continuations would get added so that this could become a bit easier in the browser, but I understand the hesitancy to do so...)

[bonzini]

> it is far from being the "default compilation target" for almost any language

That referred to the content of Gary Bernhardt's talk, not to (current) reality.

[madeofpalk]

The talk is a work of fiction, set in 2035, which describes the Bay Area as a nuclear exclusion zone.