5 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).
  - still_grokking 4y ago
    How would you do that? Could you please show a working example? What you're saying is completely impossible right now AFIK…
  - mike_hearn 4y ago
    you wouldn't have to write code specifically targeting the JNI for example Why not? You still need operations like "create object", "look up method", "invoke method", "convert type between languages" etc. WASM doesn't have any kind of polyglot layer that does this automatically. Ironically, Graal/Truffle actually do. There's a whole infrastructure where languages can expose their structures, functions, objects etc via a language-neutral in-process protocol and the compiler understands how to optimize across the transitions, so you can actually load JavaScript into Python and do those sorts of things: https://www.graalvm.org/latest/reference-manual/polyglot-programming/ https://www.graalvm.org/latest/reference-manual/polyglot-pro... The API you use to import code from other languages is standardized, so it doesn't matter what language the other side is using. But WASM doesn't do anything like that. "with wasm, you just pull in csharp.wasm, python.wasm and java.wasm, so it's just one binding layer, not three" Are these real files/projects you're talking about here? If so, can you show us these things? Because WASM seems far too low level to define a Truffle-like polyglot layer let alone make it fast.
  - 4y ago
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
    - TUSF 4y ago
      > But isn't WASI considered harmful? Lmao. The guy is just mad that WASI uses utf-8, as opposed to utf-16 (which is what Javascript uses)
    - 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).
- still_grokking 4y ago
  How would you do that? Could you please show a working example? What you're saying is completely impossible right now AFIK…
- mike_hearn 4y ago
  you wouldn't have to write code specifically targeting the JNI for example Why not? You still need operations like "create object", "look up method", "invoke method", "convert type between languages" etc. WASM doesn't have any kind of polyglot layer that does this automatically. Ironically, Graal/Truffle actually do. There's a whole infrastructure where languages can expose their structures, functions, objects etc via a language-neutral in-process protocol and the compiler understands how to optimize across the transitions, so you can actually load JavaScript into Python and do those sorts of things: https://www.graalvm.org/latest/reference-manual/polyglot-programming/ https://www.graalvm.org/latest/reference-manual/polyglot-pro... The API you use to import code from other languages is standardized, so it doesn't matter what language the other side is using. But WASM doesn't do anything like that. "with wasm, you just pull in csharp.wasm, python.wasm and java.wasm, so it's just one binding layer, not three" Are these real files/projects you're talking about here? If so, can you show us these things? Because WASM seems far too low level to define a Truffle-like polyglot layer let alone make it fast.
- 4y ago

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
  - TUSF 4y ago
    > But isn't WASI considered harmful? Lmao. The guy is just mad that WASI uses utf-8, as opposed to utf-16 (which is what Javascript uses)
  - 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...