Comment by flohofwoe
7 hours ago
I'm using WASM via Emscripten almost since the beginning but have never encountered 'rec' or 'struct' (or generally types beyond integers and floats). Why would WASM even need to know how structs are composed internally, instead of 'dissolving' them at compile time into offsets? Was this stuff coming in via the GC feature?
I've been learning to use WebAssembly directly, by hand-writing the Lisp-like assembly text, and also compiling C to Wasm without Emscripten or LLVM. It's given me a deeper appreciation for the original specification, version 1. Its technical design is a solid foundation, a lot of good thought went into it: Briging the Web Up to Speed With WebAssembly - https://github.com/WebAssembly/spec/raw/refs/tags/wg-1.0/pap...
In a way it's a complete instruction set and bytecode format, that could have been frozen in time and still be a useful addition to x86, ARM, RISC-V. It's great that the Wasm v1 specs is small enough for various implementations to arise. There are Wasm interpreters written in C, Zig, Go, Rust, as well as Wasm to C compiler, disassembler, little languages that compile to Wasm.. I see great value in that simplicity and smallness, it contributes to easier cross-platform and cross-language compatibility.
That's why newer features in the specs after v1, like garbage collection, components, interfaces, feel like they're higher-level abstractions that are not so relevant for my use case. Some feel like they could be developed outside of Wasm specs, like you said, dissolved at compile time to existing primitives. I'm guessing much of the benefit is for integrating with Rust ecosystem, and perhaps other languages gradually.
Yes, this is all part of Wasm GC. WebAssembly needs to know the structures of heap objects so that a GC can trace them and also to preserve type safety when accessing them. Treating the heap objects as uninterpreted bags of bytes wouldn't have worked because so many of their fields are references, which must remain opaque in Wasm.