> many re-implementations of things in various incompatible/slightly incompatible languages
This is why WebAssembly's lack of a garbage collector (which could be optional) strikes me as strange. What we'll get is every web page including code implementing an informally specified, bug-ridden, slow GC instead of using the excellent ones already present in browsers. I hope this will be fixed.
I understand that not every programmer and not every language wants to pay GC costs, but there are ways around that.
(Even without GC, the same applies to languages that explicitly manage memory for "speed". Their implementations will also have to work hard to provide "fast" allocators on top of the primitives provided.)
GC support [is coming][1]. Just because they didn't include it with the initial Minimum Viable Product release, doesn't mean it won't ever be available.
I thought it might be on the compiling platform to provide GC if it wants to.
As you said some devs/apps are better off without GC, but also I imagine competition would more or less ensure the most performant or overall effective platforms would end up being the de facto standards.
And some platforms (e.g. React, Vue, etc.) may find one GC tends to work better than another for them or want to implement their own.
I'm not sure if WASM can host libraries on CDNs, but if so once a user has that stuff cached from one site or another bloat wont really be a problem either.
> I thought it might be on the compiling platform to provide GC if it wants to.
Yes, the compiling platform can use WebAssembly's memory primitives to implement its own GC. But (besides the wasted work of implementing it) this is unlikely to be as efficient as a native, tuned GC on the target platform.
This is why WebAssembly's lack of a garbage collector (which could be optional) strikes me as strange. What we'll get is every web page including code implementing an informally specified, bug-ridden, slow GC instead of using the excellent ones already present in browsers. I hope this will be fixed.
I understand that not every programmer and not every language wants to pay GC costs, but there are ways around that.
(Even without GC, the same applies to languages that explicitly manage memory for "speed". Their implementations will also have to work hard to provide "fast" allocators on top of the primitives provided.)