3 ms·

> Right now we have a dozen languages that transpile to JS Not used in any meaningful amount, we don't. And in any case, a library transpiled from Elm to JS is

by untog 9y ago

> Right now we have a dozen languages that transpile to JS Not used in any meaningful amount, we don't. And in any case, a library transpiled from Elm to JS is usable by some other code that was transpiled from Typescript to JS. Will that be the same with WASM? Will I be able to make easily reusable WASM libraries? Will they all use the same mechanism to do so? All I've seen discussed is entire apps being converted.

comex 9y ago
WebAssembly modules can import from other modules: https://github.com/WebAssembly/design/blob/master/Modules.md#imports https://github.com/WebAssembly/design/blob/master/Modules.md... By itself that’s the equivalent of dynamic linking; I don’t know if anyone’s written a static linker yet, but it’s an obvious next step. However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc., and C and its sparse type system being the least common denominator.
- kodablah 9y ago
  > I don’t know if anyone’s written a static linker yet, but it’s an obvious next step. Essentially just wasm-merge [0]. > However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc., This is the biggest hurtle. Someone needs to provide a WASM interface for backends to implement and frontends to target that provides a minimal stdlib. Until then, it's libc and posix by way of emscripten. 0 - https://github.com/WebAssembly/binaryen/pull/919 https://github.com/WebAssembly/binaryen/pull/919
Matthias247 9y ago
> And in any case, a library transpiled from Elm to JS is usable by some other code that was transpiled from Typescript to JS. Will that be the same with WASM? Will I be able to make easily reusable WASM libraries? In short: No With the current transpile-to-JS mechanisms all those languages use the same object model (from Javascript), the same string types, the same garbage collector, etc. Once you compile-to-WASM, you reduce the common API surface to the WASM primitives, which are reading and writing numeric values from locations in byte arrays. To get some interoperability one would need to create a Javascript wrapper for all those WASM modules. Or in the future there might be a shared garbage collector in WASM, but even when that's the case one would require a standardized object model between all languages that compile-to-WASM and would like to interoperate.
- untog 9y ago
  That's what I was afraid of. So the OP is correct in saying that the only answer is to re-implement the same solutions in different languages. (don't get me wrong, WASM is very exciting, but the "it's going to replace Javascript entirely!" argument doesn't convince me)
- TheCoelacanth 9y ago
  So essentially the only hope for interop is for some language to gain enough traction early on that other languages implementers all want to be compatible with it so that it becomes the de-facto cross language interface like C did on most native platforms.

by untog 9y ago

comex 9y ago

WebAssembly modules can import from other modules: https://github.com/WebAssembly/design/blob/master/Modules.md#imports https://github.com/WebAssembly/design/blob/master/Modules.md... By itself that’s the equivalent of dynamic linking; I don’t know if anyone’s written a static linker yet, but it’s an obvious next step. However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc., and C and its sparse type system being the least common denominator.

kodablah 9y ago
> I don’t know if anyone’s written a static linker yet, but it’s an obvious next step. Essentially just wasm-merge [0]. > However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc., This is the biggest hurtle. Someone needs to provide a WASM interface for backends to implement and frontends to target that provides a minimal stdlib. Until then, it's libc and posix by way of emscripten. 0 - https://github.com/WebAssembly/binaryen/pull/919 https://github.com/WebAssembly/binaryen/pull/919

Matthias247 9y ago

> And in any case, a library transpiled from Elm to JS is usable by some other code that was transpiled from Typescript to JS. Will that be the same with WASM? Will I be able to make easily reusable WASM libraries? In short: No With the current transpile-to-JS mechanisms all those languages use the same object model (from Javascript), the same string types, the same garbage collector, etc. Once you compile-to-WASM, you reduce the common API surface to the WASM primitives, which are reading and writing numeric values from locations in byte arrays. To get some interoperability one would need to create a Javascript wrapper for all those WASM modules. Or in the future there might be a shared garbage collector in WASM, but even when that's the case one would require a standardized object model between all languages that compile-to-WASM and would like to interoperate.

untog 9y ago
That's what I was afraid of. So the OP is correct in saying that the only answer is to re-implement the same solutions in different languages. (don't get me wrong, WASM is very exciting, but the "it's going to replace Javascript entirely!" argument doesn't convince me)
TheCoelacanth 9y ago
So essentially the only hope for interop is for some language to gain enough traction early on that other languages implementers all want to be compatible with it so that it becomes the de-facto cross language interface like C did on most native platforms.