2. If web-assembly incorporates a GC, then it will become needlessly complicated.
3. Unnecessary complication in web-assembly means also unnecessary room for security flaws.
(4. What good is a web assembly if you can't implement an efficient garbage collector in it?)
What is wrong with open-sourcing GC code as independent libraries, so that web-app makers or (more likely) compiler developers (with less skill/time) can use them at will?
> the issue with #4 is that you would need threads w/ shared memory
But this is exactly what we need for other applications as well. For example, how would you send a large immutable data-structure across two threads? By copying it? Of course not, you just share pointers, meaning that the address space should be shared. If this is not possible, then that is a major flaw in WASM's design.
I think you have the impression that incorporating a GC into WASM makes life easier. But it doesn't. It is the exact opposite. WASM should be as simple as possible.
There's nothing that would prevent writing your own GC if you felt the need.
Since WebAsm is still Functional languages would still have the freedom to implement their own more efficient GC (avoid the write barrier in a lot of cases, scan only the young heap most of the time, etc).
This sounds a lot like "640k ought to be enough for everyone" :)
Also, it only addressed my first point.
There's nothing stopping you from implementing your own GC. But having a standardized GC (the JS engine's GC) means much simpler interop between wasm languages.
