>the initial version of WebAssembly is a terrible target if your language relies on the presence of a garbage collector.
Lack of GC was one of the appealing parts of WASM to me. Keep it simple. It is good to be careful about utilizing memory on your visitors machines, so you better spend a lot of thought on memory management.
Counter-intuitively, I feel as though GC results in better memory usage in this situation.
Option 1: you rely on every single developer to be careful and make no memory-leaking mistakes.
Option 2: you take this problem out of the hands of the specific application devs and give it to experts in memory management, who write a GC.
If this platform is going to be the future of distributed computing, just imagine the number of terrible devs who will be releasing their code upon you.
> Option 1: you rely on every single developer to be careful and make no memory-leaking mistakes.
Nobody is expecting every single developer to carefully write their own garbage collector. WASM is a compilation target for other languages. The language you're compiling defines how memory management works, be that C / Zig (do it yourself), Rust (compile time borrow checker), Swift/ObjC (Rc / arc) or Go/JS/Java/C# (full garbage collector built into the language).
For GCed languages like Go or C#, the design choice WASM makes is between:
1. The compiler injects its own garbage collector into the created webassembly modules, just like it does when compiling native binaries.
or 2. The webassembly virtual machine provides a garbage collector that any compiled code can use.
The benefit of (1) is that it makes webassembly virtual machines simpler and safer. (This is what the GP comment wants). (Also compilers can do language-specific optimizations to their own GC.)
But (2) has a bunch of benefits too:
- The GC can be higher performance (its not written in webassembly).
- Interoperability between WASM bundles written in different languages is much better. Eg it'd be easier for Go in a WASM bundle to talk to JS in the browser. Or Go and C# code to interoperate via WASM.
- The .wasm modules for GCed languages will be much smaller, since they don't need to compile in a garbage collector.
The Go/Java/C# you write will be the same. The difference is who provides the garbage collector. Your compiler, or the WASM virtual machine?
do you have an opinion on which direction is more likely? naively I'd say 2 would be better since it'd require less language-specific toolchain work for a better devexp for the end developer.
There's a draft proposal to add a built in garbage collector (option 2) to WASM. I have no idea what the current status is - maybe someone involved can chime in. I suspect some version of the WASM GC spec will land eventually.
When it does, languages like Go, C# and Java should start to become competitive with javascript as frontend web languages.