WebAssembly support now shipping in all major browsers

My point here is that it is beside the point whether it's trivial or non-trivial to implement a garbage collector. With regards to it having to be part of the module payload, that's how garbage collectors are typically implemented today, meaning it's very practical in the sense that you can just re-target that portion of your language runtime implementation like any other part without making the web a special case. Just target the new instruction set architecture and you have your garbage collector exactly as intended, tuned for the use case you designed it for.

> If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you.

It may be more difficult, but in the end also an entirely different problem. If you have implemented a garbage collecting language runtime for your language, you've already solved the problem of garbage collection.

> Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.

My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question. The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me.

It is also very practical to be able to use objects allocated and managed by the browser instead of a contiguous array of memory, but that doesn't somehow make the obvious approach less practical.

>My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question.

The hardships of the implementation are central to why it's impractical. That said, I think we may be using different definitions of the word impractical here.[0] I'm talking strictly in a general sense, that packaging an entire language's runtime with code is—for most uses right now—not sensible.

You are correct in that it's entirely possible to use GCed languages inside wasm, and indeed it has been done—I'm not disputing that.

I also understand your point about the multi-platform advantages of keeping the GC portion of the runtime inside of wasm. Funny enough that may turn on its head in the distant future once GC support lands, assuming wasm ends up being a popular compilation target outside of the web. In that case you'd have wasm-managed GC objects on desktop and mobile.

>The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me.

Lua is very lightweight. The story changes if you try to compile the .NET, JVM, Go or even V8 runtimes into wasm. All possible, but a hell of a lot more difficult.

One case study is Blazor.[1] The FAQ in its own readme states that it's not practical currently due to binary sizes, albeit not for GC-related reasons. But it will be practical. That was the gist of what I was trying to say, that GCed languages (i.e. ones that include their own runtime) are currently not terribly practical relative to the compiled alternatives, most of which are production-ready now.

Of course, having seriously evaluated Unreal Engine 4 for web use with its 50MB runtime, I view even Blazor's current 4MB binary size as quite practical, but it depends on the use case. For general web use, 4MB isn't practical.

In support of your point, I concede that whether the GC resides in the module or VM is largely immaterial to practicability as a whole. My point was that packaging the runtime with the payload is usually not sensible relative to the alternatives. I regret that I incorrectly generalized my original statement in terms of garbage collection rather than runtime overhead.

[0] https://en.oxforddictionaries.com/definition/impractical

[1] https://github.com/SteveSanderson/Blazor

I'm talking about the former as pretty much the entirety of my previous comment tried to convey.

>I also don't see the advantage of WebAssembly as a compiler target in general.

The advantage is it would be a single target.

>So it's impractical in some cases because of large binaries, not for any of the reasons you've pointed out so far. Giving WebAssembly programs a way to integrate with the VM GC will change this how, exactly?

It's impractical primarily because it's not production-ready. In the interests of pedantry however, reliance on a VM GC would likely result in a somewhat smaller binary size.

>In Blazor's case the large file size can likely be attributed to things not strictly related to the run-time, like the core libraries.

Per its readme: "This is because Mono on WASM doesn't yet have any IL stripping or minification, and bundles a large runtime that includes many desktop-related features that are irrelevant on the web."

>What is general web use, and how does it relate to WebAssembly?

Most people use the internet to visit websites. Most major websites optimize their page loads as much as possible to fit as many ads in as they can without completely tanking the user experience. Using the previous example, a 4MB binary doesn't fit that use case. It would be more the realm of specialized applications.

>What are the alternatives?

Javascript ecosystem or production-ready compiled languages that target wasm.