3 ms·

And WASM hasn't been around for as long, so WASM implementations are not as mature. There is no reason why WASM couldn't be as fast, or faster than JS, especia

And WASM hasn't been around for as long, so WASM implementations are not as mature. There is no reason why WASM couldn't be as fast, or faster than JS, especially now with WASM 3.0. Before, every programs in a managed language had to be shipped with its own GC and exception handling framework in WASM which was probably crippled by size constraints.

pjmlp 9mo ago
They still need to, because WASM GC is a MVP that only covers a subset. Any language with advanced GC algorithms, or interior pointers, will run poorly with current WASM GC. It works as long as their GC model overlaps with JS GC requirements.
- WorldMaker 9mo ago
  It's also currently only a subset of JS GC requirements at that. It's the bare minimum to share references between JS and WASM to byte arrays like Int32Array. It's like basic OS-level memory page sharing only for now. Some of the real GC tests will be strings support (because immutability/interning) and higher-level composite objects, which is all still in various draft/proposal states.
  - pjmlp 9mo ago
    Oh, even worse than I thought.