4 ms·

I'm upset WASM doesn't have any types other than numbers, so you can't export any real-world functions without relying on glue code, which converts strings and

I'm upset WASM doesn't have any types other than numbers, so you can't export any real-world functions without relying on glue code, which converts strings and objects to numbers and the other way around this is also the reason why the "hello world" of WASM is a function adding two numbers - because there are no strings in WASM https://webassembly.github.io/spec/core/syntax/types.html https://webassembly.github.io/spec/core/syntax/types.html

nitsky 4y ago
Check out the component model proposal, which adds a stable ABI for rich types like strings, arrays, structs, etc. https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model
- josephg 4y ago
  Whats the status on this? How long before the component model is something we can use?
- nuc1e0n 4y ago
  Not a great proposal IMHO and it misses the point of wasm in general. Strings and other high level data structures are distinctions the high level languages that output wasm should make. Anyone who's had to do java to .net clr interop will say how problematic it was. The only resonable way to do it was via text de/serialisation on the database or via a web based api, even on the same computer. That's crazy when you think about it. So arrays of numbers will work and have predictable performance from one wasm runtime to another. Personally, I'd prefer to see wasm not repeat the same disasterous mistakes Java made.
nuc1e0n 4y ago
Strings are only an array of numbers (codepoints). Wasm is intended as a compiler target that can be easily implemented with good performance. The text format is not a high level language on purpose. The proper term for this tool is not a compiler but an assembler because the text format is a 1-to-1 mapping of the binary output.