4 ms·

You don't, just, easily rewrite everything. Being able to just re-use is the trick!

ncruces 2y ago
Exactly. Why would you rewrite (parts of) Cargo from Rust to something that runs on the JVM, when you can use Wasm as basically an intermediate target to compile the Rust down to JVM bytecode? Or how about running something like Shellcheck (written in Haskell) on the JVM as part of a build process? You can see the same idea for the Go ecosystem (taking advantage of the Go build system) on the many repos of this org: https://github.com/wasilibs https://github.com/wasilibs
- jcmfernandes 2y ago
  This is great. The future is made of libraries packaged as WASM Components.
  - throwaway894345 2y ago
    Aren't WASM Components pretty constrained? My (very fuzzy) understanding is that they must basically manage all of their own memory, and they can only interact by passing around integer handles corresponding to objects they manage internally.
    - lukevp 2y ago
      Part of the component model is codegen to build object structures in each language so that you can pass by reference objects that have an agreed upon shape. Yes they each have their own linear memory, that’s one of the advantages of component model. It provides isolation at the library level and you don’t have to implicitly agree that each library gets the level of access your application does. It provides security against supply chain side attacks. Having said that, component model isn’t supported by all runtimes and since its binding and code gen are static at compile time, it’s not useful for every situation. Think of it like a C FFI more than a web API receiving JSON, for example. Upgrading the library version would mean upgrading your bindings and rebuilding your app binary too, the two must move in lock-step.
pjmlp 2y ago
Java already has plenty of FFI variants for that.
- jcmfernandes 2y ago
  Yes, but WASM gives you more, especially WASM Components. E.g., FFI doesn't offer sandboxing, and unloading symbols is tricky. The WIT (WebAssembly Interface Types) IDL (+ bindings codegen) makes objects' exports explicit, but more importantly, their imports too (i.e., dependencies).
  - pjmlp 2y ago
    Basically CORBA, DCOM, PDO, RMI, Jini and .NET Remoting for a new generation.
    - jcmfernandes 2y ago
      Yes, the concept is old. I may be wrong, but to me, this really seems like it, the one that will succeed. With that said, I'm sure many said the same about the technologies you enumerated... so let's see!
    - jmillikin 2y ago
      None of what 'jcmfernandes lists are part of WebAssembly. At best they can be considered related technologies, like the relationship between the JVM and JavaBeans. And in terms of design, they're closer to COM or OLE. The modern replacement for CORBA/DCOM/etc is HTTP+JSON (or gRPC), which doesn't try to abstract away the network.
      - jcmfernandes 2y ago
        Correct, they are a part of WASI. Indeed, different things, but well, tightly related. Made sense to talk about them given the chat on bridging gaps in bazel using WASM.
      - pjmlp 2y ago
blacklion 2y ago
Oh, these tools are written in languages which can be directly compiled to WebAssembly without any changes? Yes, then it make sense, thank you for clarification.
- jmillikin 2y ago
  Yeah, pretty much all of them are written in either Go or Rust. The Go tools pull in the Go standard library's Go parser to do things like compute dependencies via package imports, and the Rust ones use the Cargo libraries to parse Cargo.toml files. From the perspective of a Bazel ruleset maintainer, precompiled helper tools are much easier to provide if your language has easy cross-compilation. So maybe one day Zig will start to make an appearance too.

Exactly. Why would you rewrite (parts of) Cargo from Rust to something that runs on the JVM, when you can use Wasm as basically an intermediate target to compile the Rust down to JVM bytecode? Or how about running something like Shellcheck (written in Haskell) on the JVM as part of a build process? You can see the same idea for the Go ecosystem (taking advantage of the Go build system) on the many repos of this org: https://github.com/wasilibs https://github.com/wasilibs

jcmfernandes 2y ago
This is great. The future is made of libraries packaged as WASM Components.
- throwaway894345 2y ago
  Aren't WASM Components pretty constrained? My (very fuzzy) understanding is that they must basically manage all of their own memory, and they can only interact by passing around integer handles corresponding to objects they manage internally.
  - lukevp 2y ago
    Part of the component model is codegen to build object structures in each language so that you can pass by reference objects that have an agreed upon shape. Yes they each have their own linear memory, that’s one of the advantages of component model. It provides isolation at the library level and you don’t have to implicitly agree that each library gets the level of access your application does. It provides security against supply chain side attacks. Having said that, component model isn’t supported by all runtimes and since its binding and code gen are static at compile time, it’s not useful for every situation. Think of it like a C FFI more than a web API receiving JSON, for example. Upgrading the library version would mean upgrading your bindings and rebuilding your app binary too, the two must move in lock-step.

pjmlp 2y ago

Java already has plenty of FFI variants for that.

jcmfernandes 2y ago
Yes, but WASM gives you more, especially WASM Components. E.g., FFI doesn't offer sandboxing, and unloading symbols is tricky. The WIT (WebAssembly Interface Types) IDL (+ bindings codegen) makes objects' exports explicit, but more importantly, their imports too (i.e., dependencies).
- pjmlp 2y ago
  Basically CORBA, DCOM, PDO, RMI, Jini and .NET Remoting for a new generation.
  - jcmfernandes 2y ago
    Yes, the concept is old. I may be wrong, but to me, this really seems like it, the one that will succeed. With that said, I'm sure many said the same about the technologies you enumerated... so let's see!
  - jmillikin 2y ago
    None of what 'jcmfernandes lists are part of WebAssembly. At best they can be considered related technologies, like the relationship between the JVM and JavaBeans. And in terms of design, they're closer to COM or OLE. The modern replacement for CORBA/DCOM/etc is HTTP+JSON (or gRPC), which doesn't try to abstract away the network.
    - jcmfernandes 2y ago
      Correct, they are a part of WASI. Indeed, different things, but well, tightly related. Made sense to talk about them given the chat on bridging gaps in bazel using WASM.
    - pjmlp 2y ago

blacklion 2y ago

Oh, these tools are written in languages which can be directly compiled to WebAssembly without any changes? Yes, then it make sense, thank you for clarification.

jmillikin 2y ago
Yeah, pretty much all of them are written in either Go or Rust. The Go tools pull in the Go standard library's Go parser to do things like compute dependencies via package imports, and the Rust ones use the Cargo libraries to parse Cargo.toml files. From the perspective of a Bazel ruleset maintainer, precompiled helper tools are much easier to provide if your language has easy cross-compilation. So maybe one day Zig will start to make an appearance too.