3 ms·
This is far from trivial. Consider the WasmGC proposal, which had a somewhat similar goal. Then C# came and said "we can't use it, we have different needs". So
by afdbcreid 2mo ago
This is far from trivial. Consider the WasmGC proposal, which had a somewhat similar goal.
Then C# came and said "we can't use it, we have different needs". So did Go.
- wasmperson 2mo ago> Then C# came and said It's worse than that. The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway: https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77 They were also warned about Go (though I'm not sure if they ever actually consulted with golang devs): https://github.com/WebAssembly/gc/issues/36 https://github.com/WebAssembly/gc/issues/36 More links: https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420 https://github.com/golang/go/issues/63904 https://github.com/golang/go/issues/63904
- ack_complete 2mo agoNo interior pointers, no embedded arrays, and only a subset of Java definitely seems like an odd target. I would have expected at least two different full languages with acceptable porting overhead to be the MVP.
- afdbcreid 2mo agoI believe the MVP was chosen specifically to have the same features as JavaScript, so that browser engines can implement it without major changes. So not really an odd target.