4 ms·

WASM isn't a new idea. I will say, the one thing that WASM has "right" over say, the JVM, Roslyn, or other portable runtimes is the fact you can share WASM modu

WASM isn't a new idea. I will say, the one thing that WASM has "right" over say, the JVM, Roslyn, or other portable runtimes is the fact you can share WASM modules across language boundaries. I can't drop in use a Rust module in my Go code, at minimum, I'd need to dip into some kind of FFI. With WASM, you can just import the WASM module for usage into your language, as long as it supports WASM, regardless of original source. Its a portable format and runtime. That is the key difference than VMs of the past to me at least. It also makes sharing code that was written in say, C or C++ easier and safer too. I agree that WASM replacing Docker is something I can't "see" right now, because its just very different, but I do think the highlights above are pretty great. EDIT: Actually, I think I understand the point of WASM replacing Docker potentially which is, if WASM runtimes support the underlying operating systems sufficiently (like virtualization has to) then you could just compile what would be a container into a WASM module. IE, I could compile Postgres, Redis etc. to WASM (or more importantly, the projects could) and simply use their WASM binaries to support my application. Thats what I think they're going for here. Its hard to "see" it because there are so many unknowns (WASI doesn't have all the features currently needed for this to happen I don't think, for instance)

torginus 3y ago
I believe that's a bit strained as well - I'm pretty sure if you want to use a Rust module in Go, you also need to follow a standard calling convention analogous to cdecl in C - you'll have a hard time supporting any higher level feature across languages. The incompatibility on higher level constructs seems like much more of a bugbear to resolve. - for example, almost all popular high level languages have some idea of garbage collection/reference counting. There's a WASM GC proposal, I'm not sure how can they make it play nice with every languages idea/semantics of garbage collection as many languages place their own particular set of restrictions on GC like interior pointers/pinning/copying etc. some of which might be mutually exclusive. I could go on, but my point is that I believe there always needs to be an FFI between languages, that is usually barely more expressive than what a protobuf contract/C API would be (and we already have those)
o1y32 3y ago
JVM isn't bound to language either -- it can run bytecode generated by another language, for like, decades. But I'm afraid it has never received mainstream attention.
mike_hearn 3y ago
WASM and FFIs are orthogonal, right? WASM doesn't specify how to map a Rust Option<String> to a Go string, or a C++ std::string to a Java String object. This is what I mean about things getting conflated. Note that both the JVM and CLR do try to solve this problem, hence the name Common Language Runtime. WASM actually does far less in this area. Still, times change. If you want language interop then these days Truffle/Graal is the state of the art to beat. It actually does define both a generic inter-language FFI, but also has a compiler that understands how to compile and inline across that FFI. So in Truffleworld calling a JS function from inside a hot Rust loop isn't actually an insane or stupid thing to do because the whole thing will be compiled and optimized as a single unit, and things like maps/arrays/etc will be properly converted between languages without any data copying.
- no_wizard 3y ago
  My experience with WASM so far, is that I can import WASM modules without caring at all about FFI. They're produced, and I can use them, as is, whatever their exposed interface is. I'm not even sure Truffle/Graal is doing that across language boundaries (yet). Of course, in practice, this is basically C, C++ and Rust being used in the web browser or with V8 / Deno, because its the biggest WASM runtime there is right now, but thats changing too, as language communities are starting to seriously consider first party support for WASM. To address the point of mapping types / data from one language to another: thats the whole point of WASM, is that those languages need to only bind their output to the WASM guidelines. Its all there is to it. Valid WASM will run in any valid WASM runtime
  - mike_hearn 3y ago
    Truffle is definitely not only doing that across language boundaries but for far more languages. For example, using Ruby from JavaScript: var array = Polyglot.eval("ruby", "[1,2,42,4]") console.log(array[2]); Invoking a C/C++/Rust main method from Python: import polyglot cpart = polyglot.eval(language="llvm", path="polyglot") cpart.main() Reading a JS array from C: #include <stdio.h> #include <graalvm/llvm/polyglot.h> int main() { void *array = polyglot_eval("js", "[1,2,42,4]"); int element = polyglot_as_i32(polyglot_get_array_element(array, 2)); printf("%d\n", element); return element; } More examples here: https://www.graalvm.org/latest/reference-manual/polyglot-programming/ https://www.graalvm.org/latest/reference-manual/polyglot-pro... W.R.T. the "WASM guidelines", can you point us to these guidelines and where they define how to map a Python dict to a Java HashMap, for example? The Truffle Polyglot messaging spec does define how this is done in a way that avoids performance problems because the FFI is expressed in terms of compiler IR. WASM can't even run either of these languages natively so it can't define how they interop with each other.
pjmlp 3y ago
> With WASM, you can just import the WASM module for usage into your language, as long as it supports WASM, regardless of original source. Its a portable format and runtime. That is the key difference than VMs of the past to me at least. Welcome to 2001, .NET CLR. Welcome to 1988, IBM AS/400 and TIMI. Welcome to 1980, Amsterdam Compiler Toolkit. Welcome to .... The thing WASM has getting for itself is marketing and young generations completly cluessles of the history of bytecode environments since Burroughs Large Systems was introduced in 1961.
- preseinger 3y ago
  well, that, and performance and mindshare
  - pjmlp 3y ago
    Which wasm runtime beats the CLR? Which wasm runtime has more deployments in production than the CLR since 2001?
    - preseinger 3y ago
      nobody is deploying clr applications anywhere where wasm applies
      - pjmlp 3y ago
        The browser? Sure.
        preseinger 3y ago
        can you point me to any meaningful use of the clr in the browser? i'm not aware of any
- no_wizard 3y ago
  Which is acknowledged clearly, I know there are other approaches, and I even said the idea of WASM isn't new. Its key feature is less friction. WASM is well specified relative to other options, and doesn't rely on one language to be feature compliant, or have any one language in mind for its targeting. CLR is naturally really tied to C# / F#. The JVM is a bit better in this regard (Kotlin, Java, Clojure, Scala, and I think Julia all leverage this) because it has a better specification for doing this. I think WASM excels because its specification is much easier to digest and implement for. Writing WASM modules by hand isn't too terribly bad either (its a LISP even!). WASM also has good marketing and a good place to test it. Every evergreen browser right now can run WASM code. That makes it infinitely easier to test WASM implementations. As WASI becomes more mature, it will also make it easier to develop interop as well. I think centrally its just the right combination of good specification, ease of implementation relative to the others, and good marketing.

torginus 3y ago

I believe that's a bit strained as well - I'm pretty sure if you want to use a Rust module in Go, you also need to follow a standard calling convention analogous to cdecl in C - you'll have a hard time supporting any higher level feature across languages. The incompatibility on higher level constructs seems like much more of a bugbear to resolve. - for example, almost all popular high level languages have some idea of garbage collection/reference counting. There's a WASM GC proposal, I'm not sure how can they make it play nice with every languages idea/semantics of garbage collection as many languages place their own particular set of restrictions on GC like interior pointers/pinning/copying etc. some of which might be mutually exclusive. I could go on, but my point is that I believe there always needs to be an FFI between languages, that is usually barely more expressive than what a protobuf contract/C API would be (and we already have those)

o1y32 3y ago

JVM isn't bound to language either -- it can run bytecode generated by another language, for like, decades. But I'm afraid it has never received mainstream attention.

mike_hearn 3y ago

WASM and FFIs are orthogonal, right? WASM doesn't specify how to map a Rust Option<String> to a Go string, or a C++ std::string to a Java String object. This is what I mean about things getting conflated. Note that both the JVM and CLR do try to solve this problem, hence the name Common Language Runtime. WASM actually does far less in this area. Still, times change. If you want language interop then these days Truffle/Graal is the state of the art to beat. It actually does define both a generic inter-language FFI, but also has a compiler that understands how to compile and inline across that FFI. So in Truffleworld calling a JS function from inside a hot Rust loop isn't actually an insane or stupid thing to do because the whole thing will be compiled and optimized as a single unit, and things like maps/arrays/etc will be properly converted between languages without any data copying.

no_wizard 3y ago
My experience with WASM so far, is that I can import WASM modules without caring at all about FFI. They're produced, and I can use them, as is, whatever their exposed interface is. I'm not even sure Truffle/Graal is doing that across language boundaries (yet). Of course, in practice, this is basically C, C++ and Rust being used in the web browser or with V8 / Deno, because its the biggest WASM runtime there is right now, but thats changing too, as language communities are starting to seriously consider first party support for WASM. To address the point of mapping types / data from one language to another: thats the whole point of WASM, is that those languages need to only bind their output to the WASM guidelines. Its all there is to it. Valid WASM will run in any valid WASM runtime
- mike_hearn 3y ago
  Truffle is definitely not only doing that across language boundaries but for far more languages. For example, using Ruby from JavaScript: var array = Polyglot.eval("ruby", "[1,2,42,4]") console.log(array[2]); Invoking a C/C++/Rust main method from Python: import polyglot cpart = polyglot.eval(language="llvm", path="polyglot") cpart.main() Reading a JS array from C: #include <stdio.h> #include <graalvm/llvm/polyglot.h> int main() { void *array = polyglot_eval("js", "[1,2,42,4]"); int element = polyglot_as_i32(polyglot_get_array_element(array, 2)); printf("%d\n", element); return element; } More examples here: https://www.graalvm.org/latest/reference-manual/polyglot-programming/ https://www.graalvm.org/latest/reference-manual/polyglot-pro... W.R.T. the "WASM guidelines", can you point us to these guidelines and where they define how to map a Python dict to a Java HashMap, for example? The Truffle Polyglot messaging spec does define how this is done in a way that avoids performance problems because the FFI is expressed in terms of compiler IR. WASM can't even run either of these languages natively so it can't define how they interop with each other.

pjmlp 3y ago

> With WASM, you can just import the WASM module for usage into your language, as long as it supports WASM, regardless of original source. Its a portable format and runtime. That is the key difference than VMs of the past to me at least. Welcome to 2001, .NET CLR. Welcome to 1988, IBM AS/400 and TIMI. Welcome to 1980, Amsterdam Compiler Toolkit. Welcome to .... The thing WASM has getting for itself is marketing and young generations completly cluessles of the history of bytecode environments since Burroughs Large Systems was introduced in 1961.

preseinger 3y ago
well, that, and performance and mindshare
- pjmlp 3y ago
  Which wasm runtime beats the CLR? Which wasm runtime has more deployments in production than the CLR since 2001?
  - preseinger 3y ago
    nobody is deploying clr applications anywhere where wasm applies
    - pjmlp 3y ago
      The browser? Sure.
      - preseinger 3y ago
        can you point me to any meaningful use of the clr in the browser? i'm not aware of any
no_wizard 3y ago
Which is acknowledged clearly, I know there are other approaches, and I even said the idea of WASM isn't new. Its key feature is less friction. WASM is well specified relative to other options, and doesn't rely on one language to be feature compliant, or have any one language in mind for its targeting. CLR is naturally really tied to C# / F#. The JVM is a bit better in this regard (Kotlin, Java, Clojure, Scala, and I think Julia all leverage this) because it has a better specification for doing this. I think WASM excels because its specification is much easier to digest and implement for. Writing WASM modules by hand isn't too terribly bad either (its a LISP even!). WASM also has good marketing and a good place to test it. Every evergreen browser right now can run WASM code. That makes it infinitely easier to test WASM implementations. As WASI becomes more mature, it will also make it easier to develop interop as well. I think centrally its just the right combination of good specification, ease of implementation relative to the others, and good marketing.