Hacker News Reader

Comment by munificent | Hacker News Reader

Every Turing complete language is a universe language runtime.

The interesting question is whether it's a good universal language runtime, and what kind of languages it's best for.

Today, WASM doesn't support GC, which means it's unlikely to be a good runtime for any language that wants to automatically manage memory and interact with the DOM (which needs to have its own GC).

View on HN

> Today, WASM doesn't support GC,

Is that really a problem considering most languages already implement a VM with GC?

Yes, because it means shipping the language's own VM down with your application. It also means that VM's GC has to interact with the browser's own GC for DOM nodes if you want to be able to touch the DOM.

What about Haskell, which compiles everything - including the garbage collector - into a static binary? Or is it not possible to have GC-thread running with WebAssembly?

I can't remember if threading support is in yet, but it should be possible. The downside is that it will be a rather hefty binary the user has to download.

Eh, cut one tracking script or bloated PNG and you've saved a lot of download size.

No threads yet, they're coming though: http://webassembly.org/docs/future-features/

That's doable, but it means your application needs to include the runtime and GC. That's a lot of code to push down the wire.

> Today, WASM doesn't support GC

That's true for now, but they're [planning][1] on adding support for that in the near future.

[1]: https://github.com/WebAssembly/design/blob/master/GC.md

That page has been there for quite some time. :)

Yep, GC support has been part of WASM's long-term goals since almost the beginning. April 30, 2015: https://github.com/WebAssembly/design/commit/16687d30a0859b2...

...and no progress yet.

GC was not part of [the MVP][1], and the MVP itself was only finished around 2 weeks ago, so of course not. They haven't even had an opportunity to work on it yet. Like I said, "long-term goals".

If you want to get an idea of where GC is on the priorities list, have a look at the [roadmap][2]. There are still other things they have to deal with before they start working on GC support, but it's coming.

[1]: http://webassembly.org/docs/mvp/

[2]: http://webassembly.org/roadmap/

So wasm is a bytecode format like Java or C#'s IL except it basically has no runtime?

Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Hell if we use one of those bytecode formats we could reuse the runtime too!

I'm sure there's probably 20+ bytecode formats and I'm rolling my eyes that we need yet another for the web....

This has been brought up several times in this thread, but none of those bytecodes is sufficient. LLVM is not platform-agnostic, JVM/IL are sub-optimal for languages like C++.

None of those platforms' security models are as good as the web's, either, nor are their runtimes able to work well in that context.

Java (including dex) and IL bytecodes are too high level. They assume that everything is laid out in garbage collected classes.

This basically means that programming languages usually have to be specially designed for them. There's ironpython, but it's not fully compatible with python for instance.

LLVM IR is designed as a compiler IR and hardly useful for this usecase, as it is unstable, target-specific and has a complicated largely undocumented bitcode format (I don't know any reimplementations). It has been tried with PNaCl and the original SPIR, but both projects abandoned LLVM-IR/ were abandoned.

>Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough?

Because the major browser devs that designed WebAssembly are not smart enough to have thought this

We had Java in the browser for a while.

It sucked.

As others have already pointed out, this has been tried before. Turns out that some people are opposed to shipping LLVM with the browser, or any other large existing codebase.

The reality is that WASM has to target the existing JavaScript backends in every popular browser. And now you can't use LLVM, because the backends in question typically only handle reducible control flow, etc. Conversion from LLVM to a form that your JavaScript backend supports is relatively expensive and not something you want to do on every load.

Reply on news.ycombinator.com