|
| ▲ | discreteevent an hour ago | parent | next [-] |
| > Second, GCed languages need to be willing to fit with the web/WASM GC model Suppose the Go people make a special version of Go for Wasm. What do you think are the chances of that being supported in 5 years time? |
| |
| ▲ | JoshTriplett 39 minutes ago | parent [-] | | I think it'd be supported by them the moment they ship it. Whether others will be excited to use it is an open question. There's no central registry of "languages supported for WebAssembly", by design; it supports any language that can compile to standards-compliant WebAssembly. |
|
|
| ▲ | cogman10 4 hours ago | parent | prev [-] |
| > Second, GCed languages need to be willing to fit with the web/WASM GC model I think most languages could pretty easily use WASM GC. The main issue comes around FFI. That's where things get nasty. |
| |
| ▲ | pjmlp 3 hours ago | parent [-] | | WasmGC doesn't support interior pointers, and is quite primitive in available set of operations, this is quite relevant if you care about performance, as it would be a regression in many languages, hence why it has largely been ignored, other than the runtimes that were part of the announcement. | | |
| ▲ | cogman10 an hour ago | parent [-] | | Oh interesting. In java land the fact that you effectively don't have pointers but rather everything is an object reference, this ends up not being an issue. I wonder if the WASM limitation is related to the fact that JavaScript has pretty similar semantics with no real concept of a "pointer". It means to get that interior pointer, you'd need to also introduce that concept into the GC of browsers which might be a bit harder since it'd only be for WASM. |
|
|