[andreaTP]

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

[ncruces]

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

[jcmfernandes]

This is great. The future is made of libraries packaged as WASM Components.

[blacklion]

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]

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.

[pjmlp]

Java already has plenty of FFI variants for that.

[jcmfernandes]

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).