3 ms·

> Reference types maybe. But I've yet to see a convincing argument as to why they are absolutely necessary. Are you referring to WASM GC here (or managed memor

> Reference types maybe. But I've yet to see a convincing argument as to why they are absolutely necessary. Are you referring to WASM GC here (or managed memory in general)? If so, I think the main compelling reason is interop. Without GC in underlying architecture, any managed language targeting WASM must include its own runtime and GC. If you then want to write a polyglot program using multiple languages, you now have a single WASM executable containing multiple garbage collectors each managing their own objects. If you end up with cycles between those different managed heaps, you can end up in a situation where the GCs are unable to reclaim memory because they don't understand cross GC cycles. This is why Chrome did Oilpan [1]: so that they could more easily handle cycles between the DOM, JS heap, and (aspirationally at the time) Dart VM heap. A more general user-value proposition argument is that putting the GC in the WASM implementation means any improvements made to it are amortized across all managed languages that target WASM. Also, it makes applications written in managed languages and compiled to WASM smaller because they don't have to ship a runtime and GC with the app. [1]: https://chromium.googlesource.com/v8/v8/+/main/include/cppgc/README.md https://chromium.googlesource.com/v8/v8/+/main/include/cppgc...

smolder 4y ago
I'm likely in the minority in my thinking, but I don't think targeting wasm with managed languages is such a great use case for wasm anyway, and so it wasn't worth building in GC to support. For the times you want to, something light like reference counting should be easy enough.
- munificent 4y ago
  I'm biased since I work on a managed language that targets the web, but I strongly believe that it is a great use case for WASM. Most programs targeting WASM are client-side apps with rich user experiences and I believe all but a small fraction of users would be better served implementing rich UIs in managed languages. Doing UI work in C++ (which I have done plenty of) is a special exercise is pain for almost no upside. GC is great.
  - discreteevent 4y ago
    I went back to that pain a few years ago after many years away from it. After a few months I got right back in the swing of things. Spending my days arranging and solving little memory ownership problems.I got to thinking: "This is programming". And I didn't really mind it. But every so often I had to be honest and remind myself of what I had noticed at the beginning: Thinking about and managing memory is a colossal waste of time, even with smart pointers and the like - The machine can do that and has been able to do it efficiently for most things for a long time.
  - smolder 4y ago
    JavaScript is already a GC'd language effective at UI, so it doesn't seem to me like there's a strong need for wasm to fill the same role. Rather, it seems to me like wasm is better suited to accelerating processing-heavy tasks those rich web apps depend on, like custom [de]compression, ML models, data processing, image processing or simulation of some kind.
- jacobp100 4y ago
  If your language uses a tracing GC, you can’t just add reference counting and expect existing programs to work without memory leaks

smolder 4y ago

I'm likely in the minority in my thinking, but I don't think targeting wasm with managed languages is such a great use case for wasm anyway, and so it wasn't worth building in GC to support. For the times you want to, something light like reference counting should be easy enough.

munificent 4y ago
I'm biased since I work on a managed language that targets the web, but I strongly believe that it is a great use case for WASM. Most programs targeting WASM are client-side apps with rich user experiences and I believe all but a small fraction of users would be better served implementing rich UIs in managed languages. Doing UI work in C++ (which I have done plenty of) is a special exercise is pain for almost no upside. GC is great.
- discreteevent 4y ago
  I went back to that pain a few years ago after many years away from it. After a few months I got right back in the swing of things. Spending my days arranging and solving little memory ownership problems.I got to thinking: "This is programming". And I didn't really mind it. But every so often I had to be honest and remind myself of what I had noticed at the beginning: Thinking about and managing memory is a colossal waste of time, even with smart pointers and the like - The machine can do that and has been able to do it efficiently for most things for a long time.
- smolder 4y ago
  JavaScript is already a GC'd language effective at UI, so it doesn't seem to me like there's a strong need for wasm to fill the same role. Rather, it seems to me like wasm is better suited to accelerating processing-heavy tasks those rich web apps depend on, like custom [de]compression, ML models, data processing, image processing or simulation of some kind.
jacobp100 4y ago
If your language uses a tracing GC, you can’t just add reference counting and expect existing programs to work without memory leaks