> The hardships of the implementation are central to why it's 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.
>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'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.
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.