4 ms·

The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage coll

The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling. I'm not saying that it is impossible, but you would end up pretty much building a new language with all the required features, sitting next to the useless array-based thing.

couchand 3y ago
> The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling. WASM spec authors and implementors seem to agree that this all can be naturally handled by providing direct bindings to regular web APIs in WASM. I would tend to agree... Those don't exactly seem core to the design of the runtime?
- NohatCoder 3y ago
  The DOM is garbage collected, you cannot hold a reference to a DOM element in a non-garbage-collected environment without having to manually mark as held and free. Remember that some old IEs had memory leaks because one could make circular references through the DOM and JavaScript, and they each had separate garbage collectors. Well working garbage collection is not an afterthought, and you can't get two distinct garbage systems to work together in the seamless manner that a single system can operate.
  - couchand 3y ago
    I have honestly no idea what you're saying isn't possible. I've been writing a bunch of Rust code running in browsers, for work and play. I'm not futzing with the details, I just use wasm-bindgen and web-sys. I've honestly never worried about garbage collection before, one of the professional hazards of working with a well-designed Rust API. I guess that web-sys provides types with a Drop impl that tell the browser side the object is dead. > without having to manually mark as held and free. I guess that's what you're worried about? It's never been a concern of mine. Maybe if one were writing WASM by hand?
hutzlibu 3y ago
Yeah, but it is kind of hard to do right and they are working towards it. How would starting from scratch solve that?
- NohatCoder 3y ago
  It wouldn't solve the issue, but it would remove all the things in the way of one competent person sitting down and writing a spec.
  - hutzlibu 3y ago
    Writing a spec and implementing a spec are 2 different things. But they are connected. A spec can sound good in theory, but can turn out to be allmost impossible to implement. Do you think, you could write a better spec for wasm2, that browser vendors can realistically implement? Well, they are open for participation.
aseipp 3y ago
The ability to support GC'able DOM references in browsers through integration with the host-side GC is absolutely being worked on, it just took several years to stabilize because it's a tricky feature. It will also allow GC'd languages to target standalone runtimes more easily. The developers just didn't want to block the early 1.0 spec, early toolchain and software support, etc. all on that. It was just easier to ship the C/C++ style memory management model because a lot of existing code could immediately be reused and it was easier to implement. But it was always planned from a very early phase to have GC integration, at minimum, since web usage was always a big priority. The string story is a bit unfortunate (how to handle conversions between modules in different languages). Until the component model is fully fleshed out I don't think there's a clear answer here besides things like bindgen-style interfaces, but I agree it's a sore spot. I don't know what a rewrite of the spec would achieve at this point since most of these things would be impossible to get right on the first try, I suspect, and the current one is actually pretty good for the cases it does support.
- NohatCoder 3y ago
  If you do a rewrite you can throw away the memory buffer and handle all data with opaque pointers, thus allowing complete integration with the GC. And yes, you could just leave the buffer dangling there, and tell people not to use it, but it doesn't ease any part of the task of designing the new thing.

couchand 3y ago

> The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling. WASM spec authors and implementors seem to agree that this all can be naturally handled by providing direct bindings to regular web APIs in WASM. I would tend to agree... Those don't exactly seem core to the design of the runtime?

NohatCoder 3y ago
The DOM is garbage collected, you cannot hold a reference to a DOM element in a non-garbage-collected environment without having to manually mark as held and free. Remember that some old IEs had memory leaks because one could make circular references through the DOM and JavaScript, and they each had separate garbage collectors. Well working garbage collection is not an afterthought, and you can't get two distinct garbage systems to work together in the seamless manner that a single system can operate.
- couchand 3y ago
  I have honestly no idea what you're saying isn't possible. I've been writing a bunch of Rust code running in browsers, for work and play. I'm not futzing with the details, I just use wasm-bindgen and web-sys. I've honestly never worried about garbage collection before, one of the professional hazards of working with a well-designed Rust API. I guess that web-sys provides types with a Drop impl that tell the browser side the object is dead. > without having to manually mark as held and free. I guess that's what you're worried about? It's never been a concern of mine. Maybe if one were writing WASM by hand?

hutzlibu 3y ago

Yeah, but it is kind of hard to do right and they are working towards it. How would starting from scratch solve that?

NohatCoder 3y ago
It wouldn't solve the issue, but it would remove all the things in the way of one competent person sitting down and writing a spec.
- hutzlibu 3y ago
  Writing a spec and implementing a spec are 2 different things. But they are connected. A spec can sound good in theory, but can turn out to be allmost impossible to implement. Do you think, you could write a better spec for wasm2, that browser vendors can realistically implement? Well, they are open for participation.

aseipp 3y ago

The ability to support GC'able DOM references in browsers through integration with the host-side GC is absolutely being worked on, it just took several years to stabilize because it's a tricky feature. It will also allow GC'd languages to target standalone runtimes more easily. The developers just didn't want to block the early 1.0 spec, early toolchain and software support, etc. all on that. It was just easier to ship the C/C++ style memory management model because a lot of existing code could immediately be reused and it was easier to implement. But it was always planned from a very early phase to have GC integration, at minimum, since web usage was always a big priority. The string story is a bit unfortunate (how to handle conversions between modules in different languages). Until the component model is fully fleshed out I don't think there's a clear answer here besides things like bindgen-style interfaces, but I agree it's a sore spot. I don't know what a rewrite of the spec would achieve at this point since most of these things would be impossible to get right on the first try, I suspect, and the current one is actually pretty good for the cases it does support.

NohatCoder 3y ago
If you do a rewrite you can throw away the memory buffer and handle all data with opaque pointers, thus allowing complete integration with the GC. And yes, you could just leave the buffer dangling there, and tell people not to use it, but it doesn't ease any part of the task of designing the new thing.