3 ms·

> Or, easliy write different packages in different languages and combine them into one app. Just because the binary format can be shared doesn't mean code easi

> Or, easliy write different packages in different languages and combine them into one app. Just because the binary format can be shared doesn't mean code easily can. There's a tradeoff between requiring lots of glue or sharing a common lib across the langs. Either way, in WASM's current state, only the raw memory is shared and the only types are numeric primitives that can be used to address that memory. How each language lays out, for example, strings may be incompatible and most of the time where I've had to combine WASM libs for things like strings, there is a fallback to C-style (null-term'd or passing the length around). So, while the common binary format will help open new architectures to existing langs, combining code from different langs still requires manual work and may be underperforming due to requiring they speak to each other in the lowest common denominator of raw byte arrays. Maybe some group will step up and federate a new libc for the WASM generation (even if there's no code and it only defines memory layouts). Even other proposals (GC w/ records/structs, host binding, ref types, etc) that bring higher level features don't necessarily solve interoperability issues.

skybrian 9y ago
In practice, most WASM languages are going to want good interop with JavaScript, so if nothing else is done, I expect that would become the standard for foreign functions, much like C FFI is on the desktop. For example, look at what Rust is doing [1]. For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? JavaScript strings aren't perfect (I prefer how Go does it) but they're usually good enough. [1] https://github.com/koute/stdweb https://github.com/koute/stdweb
- kodablah 9y ago
  > For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? This doesn't really exist unless you mean they need to not operate on the strings in their own memory and instead make a bunch of JS calls to operate on strings. That has overhead. Otherwise you have to use some approach to get the string to an array buffer (e.g. TextEncoder, charCodeAt, etc) and even though they are probably utf-8 internally, the step still exists to get them to WASM memory. For the GP's post about combining languages, it's no fun to do all of this to use a WASM Rust string in WASM Go (this is what I meant about "lowest common denominator").
  - derefr 9y ago
    > That has overhead. Yeah, but if those strings are destined for, say, the DOM, in such a way where you're going to constantly mutate little bits of the string while it's in the DOM, then it's probably less overhead to keep the string as a foreign object handle that you can send commands to from WASM to modify the string in place in JS VM memory, than it is to keep the string in the WASM memory buffer and "blit" it to JavaScript land whenever you change it. (Consider: how would you implement something like the Atom editor in WASM with as little additional overhead as possible?) Also, maybe this overhead can be reduced. Picture an enhanced ArrayBuffer type specifically for WASM to use, that acts like virtual memory, with an MMU API attached to map Javascript objects into it—facilitating a kind of DMA. Or, allowing you to define "IO ports" in the memory space that WASM can write to to generate Nagle-chunked message events for JS-land, and which will appear to JS-land as a Javascript Service Worker endpoint that can be addressed with messages that will be turned into a buffered stream of bytes WASM can pull out of the same IO port.
- robocat 9y ago
  > it might be nice to use JavaScript strings directly, without needing to convert them at the border? JavaScript strings are UTF-16, which is incompatible with most languages. How the strings are stored internally as bytes is different for different browsers (e.g. optimisations for const strings, short strings, ascii only strings, string buffers). The best you could get would be an API for a "string object".

skybrian 9y ago

In practice, most WASM languages are going to want good interop with JavaScript, so if nothing else is done, I expect that would become the standard for foreign functions, much like C FFI is on the desktop. For example, look at what Rust is doing [1]. For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? JavaScript strings aren't perfect (I prefer how Go does it) but they're usually good enough. [1] https://github.com/koute/stdweb https://github.com/koute/stdweb

kodablah 9y ago
> For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? This doesn't really exist unless you mean they need to not operate on the strings in their own memory and instead make a bunch of JS calls to operate on strings. That has overhead. Otherwise you have to use some approach to get the string to an array buffer (e.g. TextEncoder, charCodeAt, etc) and even though they are probably utf-8 internally, the step still exists to get them to WASM memory. For the GP's post about combining languages, it's no fun to do all of this to use a WASM Rust string in WASM Go (this is what I meant about "lowest common denominator").
- derefr 9y ago
  > That has overhead. Yeah, but if those strings are destined for, say, the DOM, in such a way where you're going to constantly mutate little bits of the string while it's in the DOM, then it's probably less overhead to keep the string as a foreign object handle that you can send commands to from WASM to modify the string in place in JS VM memory, than it is to keep the string in the WASM memory buffer and "blit" it to JavaScript land whenever you change it. (Consider: how would you implement something like the Atom editor in WASM with as little additional overhead as possible?) Also, maybe this overhead can be reduced. Picture an enhanced ArrayBuffer type specifically for WASM to use, that acts like virtual memory, with an MMU API attached to map Javascript objects into it—facilitating a kind of DMA. Or, allowing you to define "IO ports" in the memory space that WASM can write to to generate Nagle-chunked message events for JS-land, and which will appear to JS-land as a Javascript Service Worker endpoint that can be addressed with messages that will be turned into a buffered stream of bytes WASM can pull out of the same IO port.
robocat 9y ago
> it might be nice to use JavaScript strings directly, without needing to convert them at the border? JavaScript strings are UTF-16, which is incompatible with most languages. How the strings are stored internally as bytes is different for different browsers (e.g. optimisations for const strings, short strings, ascii only strings, string buffers). The best you could get would be an API for a "string object".