In most cases it isn't non-trivial, and that's further compounded by the fact that the GC currently has to be part of the module payload at the moment.
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.
>... but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.
Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.
Also I suggest reading the sibling comment that Steve Klabnik replied with prior. The wasm host bindings proposal is now separate from the GC proposal.
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
That's a very general statement. There are many hurdles that will make porting some things to WebAssembly a pain, but I don't think GC in particular is one of them.
> 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.
I don't we have a different idea of what impractical means. I am not talking so much about porting an entire language run-time for a language with a very system dependent run-time, and I am not talking about useful libraries of these languages, I am talking about garbage collection.
> 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.
I doubt that using a single opaque garbage collector is a good option for many languages. It's interesting and would certainly make the implementation of new languages easier, but a garbage collector that performs well will probably always be quite language dependent. I also don't see the advantage of WebAssembly as a compiler target in general. We already have LLVM IR and the tooling that makes it a (relative) breeze to work with independent of the target.
> 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.
Don't ignore that it's a very broadly applicable and quite popular language. There are plenty of languages not particularly dependent on large runtimes that use garbage collectors. It is not fair to conclude that a language with a garbage collector necessarily has a very complex runtime when implementations of the concept have existed since the late 50s. CLR (I assume that's what you mean by .NET), JVM and V8 are all JIT compilers. Porting that likely dwarfs the complexity of porting their garbage collectors. As for Go, I'm not sure why porting its run-time would be that much of a hassle. For JVM, there are already plenty of relatively tiny implementations.
> 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.
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? 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.
> 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.
What is general web use, and how does it relate to WebAssembly? By jamming this technology into a browser in the first place, we've already conceded that the web is a generic application platform for which using plain documents or simple JavaScript is sometimes unsuitable. I don't necessarily agree that it should be, but here we are, and there are plenty of uses, given those terms, where large binary sizes may be justifiable. A large download may be worthwhile if it ends up in my browser cache and I am likely to use the application often. That doesn't mean it's suitable for serving ads in novel ways or implementing trivial web applications that you can easily implement in JS.
> 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.
What are the alternatives? As far as I am concerned, it's either using regular non-web applications or using plain JS. If that's what you mean, I agree that those alternatives are better in a large majority of cases. The best case scenario is that WebAssembly will end up being "here's something closely resembling the CPU, here's some memory, here's some way to access and manage VM objects, and here's a way for JS to call your code". That's not going to make it much easier to port a language run-time or its libraries than it is for any other platform. It will make it easier to write code that interacts with the existing browser environment.
