6 ms·

It's also valuable for running code written in <random language> to be executed in <another random language>. Write a library in Rust and compile it to WASM, t

It's also valuable for running code written in <random language> to be executed in <another random language>. Write a library in Rust and compile it to WASM, theoretically any language with WASM bindings could run it. This could really make niche languages more easily adopted if their execution environment supported libraries in WASM. Imagine using Java's JDBC from something like Nim. Nim could take advantage of a 30 year old mature and fast database access framework without haveing to envest that ime and effort themselves. Or even something more modern like the polars dataframe library.

ptx 4y ago
> Imagine using Java's JDBC from something like Nim. You can already do this with JNI. How does WASM improve things? In both cases (WASM or native code) you get the overhead of two runtimes and the hassle of converting data types, don't you?
- kaba0 4y ago
  GraalVM’s polyglot execution does solve this problem, it can even optimize across language barriers. (But it runs native languages as LLVM “bitcode” basically, not natively)
  - merb 4y ago
    GraalVM will Not succeed, because every language needs Tour be reimplemented in graal, in wasm every language just needs a wasm Target. Also Java is really slow Boy adding a wasm Target. Most languages have a way to run on a wasm engine.
    - kaba0 4y ago
      They have to be implemented as interpreters only though. > Most languages have a way to run on a wasm engine But it is basically useless for managed languages that as of yet has to bring their runtimes as well.
      - int_19h 4y ago
        It's not useless, it's just a lower layer in the stack. Decoupling high-level managed runtimes from underlying low-level bytecode makes a lot of sense. Delivery is another question, and we'll probably solve that by caching common runtimes.
- paulgb 4y ago
  Even if the feature set were limited to what’s possible with Java/JNI, the fact that Oracle does not own any piece of it is a feature in its own right.
  - kaba0 4y ago
    Dead horse. Google has more control everything web related (including wasm) than oracle does over Java.
- fschuett 4y ago
  WASM is executable from every language to every language, you wouldn't have to write code specifically targeting the JNI for example. Say you want to use a PDF library from Java, a web server from C# and some scripts someone wrote in Python, and for whatever reason your preferred language of the day is Haskell. In the normal case you'd have to rely on someone to maintain Java -> Haskell, C# -> Haskell and Python -> Haskell glue code. But with wasm, you just pull in csharp.wasm, python.wasm and java.wasm, so it's just one binding layer, not three. It's often the case that people choose languages based on the availability of the libraries written in those languages. The goal of non-browser WASM is to get rid of that and to minimize the friction of inter-language communication, so you don't have to rewrite it in $language. WASM is not tied to any language (like the JNI).
  - return_to_monke 4y ago
    That does look pretty awesome - wouldn't it hurt the performance tho? Especially with the DB Example, a database usually needs to be fast.
    - clscott 4y ago
      Sure, maybe it's not as fast to execute as another implementation, but having ANY implementation is far more useful than none at all. Here's an example where performance wouldn't matter as much: Let's say I'm the author of a programming language and I want to add a db layer to my standard lib. Via WASM I can use a working backend while I'm protyping the API for my db layer. If the performance isn't fast enough I can start implementing my own "native" version with feature parity. I can then use some of the tests from the original library (via WASM) to make sure my implementation has feature parity to the original.
    - fschuett 4y ago
      In the short term, you wouldn't want to run databases in WASM. You could, but it's not really worth the effort, as long as the WASM runtime allows TCP connections, you can just connect to any hosted DB as usual. For performance, we ship three compiler backends: LLVM (fast execution, but slowest compilation), cranelift and singlepass (our own compiler, very fast compilation and you can compile untrusted code - but slowest execution). There is a slowdown, but the goal is to keep that at a minimum (proper performance tracking is on the bucket list). We are pre-compiling the python.wasm (which was already pre-optimized when the compilation to WASM happened) with LLVM, so you should get assembly that is very close to the native execution, with the exception of the necessary VM overhead. The goal is to make it so that the interoperability gains are worth the performance hit.
MuffinFlavored 4y ago
> Write a library in Rust and compile it to WASM this misses the fact that (unless I'm wrong), WASM by itself can't really do anything like file system/network operations I know that's not the main usecase of where to put WASM logic that needs to be performant (it's the opposite really) I just think it's worth calling out that a WASM library really can't do much from what I understand. Like... basic math? You have to supply it (through a WASM runtime) interop to other functions it can call... I think? Would love to be taught/proven wrong.
- nateabele 4y ago
  This is where WASI (WebAssembly System Interface) comes in.
  - TobyTheDog123 4y ago
    But isn't WASI considered harmful? I absolutely disagree with ASC's stance on this, but it seems that the AssemblyScript project at least wants nothing to do with that kind of thing: [1] https://devclass.com/2022/09/08/assemblyscript-project-wasi-damages-open-standards-and-the-web/ https://devclass.com/2022/09/08/assemblyscript-project-wasi-... [2] https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html [3] https://github.com/WebAssembly/WASI/issues/401 https://github.com/WebAssembly/WASI/issues/401
    - deleted 4y ago
      [deleted]
    - codeflo 4y ago
      It's my understanding that WASI is using Unix-like abstractions, because they also target native execution, while the AssemblyScript would prefer web-like abstractions, because they exclusively target the browser. From your second link at least, this seems like the main technical complaint: > Languages that would naturally fit the Web platform not only are overlooked, but WASI's self-imposed abstinence of Web concepts undermines other languages' interoperability potential with JS and the Web platform specifically. The problem is that objectively, the web platform is garbage. Half-baked, weirdly incomplete abstractions, most of can only be rationally explained as either historical accidents or the aftermath of political fights on standards committees. Why would anyone base a new abstraction around those if they don't strictly have to?
cpeterso 4y ago
Firefox uses this approach to create a lightweight, in-process sandbox (called "RLBox") for some third-party libraries. The library is compiled from C/C++ to wasm and then wasm is transpiled back to C++, all at Firefox compile time so no wasm compilation is needed at Firefox run time. https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

ptx 4y ago

> Imagine using Java's JDBC from something like Nim. You can already do this with JNI. How does WASM improve things? In both cases (WASM or native code) you get the overhead of two runtimes and the hassle of converting data types, don't you?

kaba0 4y ago
GraalVM’s polyglot execution does solve this problem, it can even optimize across language barriers. (But it runs native languages as LLVM “bitcode” basically, not natively)
- merb 4y ago
  GraalVM will Not succeed, because every language needs Tour be reimplemented in graal, in wasm every language just needs a wasm Target. Also Java is really slow Boy adding a wasm Target. Most languages have a way to run on a wasm engine.
  - kaba0 4y ago
    They have to be implemented as interpreters only though. > Most languages have a way to run on a wasm engine But it is basically useless for managed languages that as of yet has to bring their runtimes as well.
    - int_19h 4y ago
      It's not useless, it's just a lower layer in the stack. Decoupling high-level managed runtimes from underlying low-level bytecode makes a lot of sense. Delivery is another question, and we'll probably solve that by caching common runtimes.
paulgb 4y ago
Even if the feature set were limited to what’s possible with Java/JNI, the fact that Oracle does not own any piece of it is a feature in its own right.
- kaba0 4y ago
  Dead horse. Google has more control everything web related (including wasm) than oracle does over Java.
fschuett 4y ago
WASM is executable from every language to every language, you wouldn't have to write code specifically targeting the JNI for example. Say you want to use a PDF library from Java, a web server from C# and some scripts someone wrote in Python, and for whatever reason your preferred language of the day is Haskell. In the normal case you'd have to rely on someone to maintain Java -> Haskell, C# -> Haskell and Python -> Haskell glue code. But with wasm, you just pull in csharp.wasm, python.wasm and java.wasm, so it's just one binding layer, not three. It's often the case that people choose languages based on the availability of the libraries written in those languages. The goal of non-browser WASM is to get rid of that and to minimize the friction of inter-language communication, so you don't have to rewrite it in $language. WASM is not tied to any language (like the JNI).
- return_to_monke 4y ago
  That does look pretty awesome - wouldn't it hurt the performance tho? Especially with the DB Example, a database usually needs to be fast.
  - clscott 4y ago
    Sure, maybe it's not as fast to execute as another implementation, but having ANY implementation is far more useful than none at all. Here's an example where performance wouldn't matter as much: Let's say I'm the author of a programming language and I want to add a db layer to my standard lib. Via WASM I can use a working backend while I'm protyping the API for my db layer. If the performance isn't fast enough I can start implementing my own "native" version with feature parity. I can then use some of the tests from the original library (via WASM) to make sure my implementation has feature parity to the original.
  - fschuett 4y ago
    In the short term, you wouldn't want to run databases in WASM. You could, but it's not really worth the effort, as long as the WASM runtime allows TCP connections, you can just connect to any hosted DB as usual. For performance, we ship three compiler backends: LLVM (fast execution, but slowest compilation), cranelift and singlepass (our own compiler, very fast compilation and you can compile untrusted code - but slowest execution). There is a slowdown, but the goal is to keep that at a minimum (proper performance tracking is on the bucket list). We are pre-compiling the python.wasm (which was already pre-optimized when the compilation to WASM happened) with LLVM, so you should get assembly that is very close to the native execution, with the exception of the necessary VM overhead. The goal is to make it so that the interoperability gains are worth the performance hit.

MuffinFlavored 4y ago

> Write a library in Rust and compile it to WASM this misses the fact that (unless I'm wrong), WASM by itself can't really do anything like file system/network operations I know that's not the main usecase of where to put WASM logic that needs to be performant (it's the opposite really) I just think it's worth calling out that a WASM library really can't do much from what I understand. Like... basic math? You have to supply it (through a WASM runtime) interop to other functions it can call... I think? Would love to be taught/proven wrong.

nateabele 4y ago
This is where WASI (WebAssembly System Interface) comes in.
- TobyTheDog123 4y ago
  But isn't WASI considered harmful? I absolutely disagree with ASC's stance on this, but it seems that the AssemblyScript project at least wants nothing to do with that kind of thing: [1] https://devclass.com/2022/09/08/assemblyscript-project-wasi-damages-open-standards-and-the-web/ https://devclass.com/2022/09/08/assemblyscript-project-wasi-... [2] https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html [3] https://github.com/WebAssembly/WASI/issues/401 https://github.com/WebAssembly/WASI/issues/401
  - deleted 4y ago
    [deleted]
  - codeflo 4y ago
    It's my understanding that WASI is using Unix-like abstractions, because they also target native execution, while the AssemblyScript would prefer web-like abstractions, because they exclusively target the browser. From your second link at least, this seems like the main technical complaint: > Languages that would naturally fit the Web platform not only are overlooked, but WASI's self-imposed abstinence of Web concepts undermines other languages' interoperability potential with JS and the Web platform specifically. The problem is that objectively, the web platform is garbage. Half-baked, weirdly incomplete abstractions, most of can only be rationally explained as either historical accidents or the aftermath of political fights on standards committees. Why would anyone base a new abstraction around those if they don't strictly have to?

cpeterso 4y ago

Firefox uses this approach to create a lightweight, in-process sandbox (called "RLBox") for some third-party libraries. The library is compiled from C/C++ to wasm and then wasm is transpiled back to C++, all at Firefox compile time so no wasm compilation is needed at Firefox run time. https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...