[mc_woods]

There are compelling applications for WASM in the embedded space, here we run C / C++ applications and WASM supports this well. We can also run other languages compiled to WASM too.

On the server side this is less clear. Typically we don't write system level languages server side - we use other languages, like Ruby, Python, JavaScipt etc. These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient. The benefit to the cloud / infrastructure provider is often not-clear, not when it's possible to run these very same applications in existing infrastructure. On the server side the benefit to the application developer is also not clear. There are few providers who have infrastructure to support WASM applications directly. You'd really need to see the big 3 cloud providers look at supporting WASM directly, without hypervisors / vm / container technology under it, to realize any performance improvements and hence pass on some cost benefit to the developer ecosystem.

"running stuff in the browser"; isn't old news. There are a growing number of applications that are migrating toward web-based UI and for these WASM is really useful. WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world....

Rust-Focus; yes, you are correct the existing technology, with the exception of perhaps WAMR and CloudEdge runtimes are rust based. As WasmTime is the only standalone technology which currently supports preview2, and it's written in rust, then the associated examples and tooling are naturally rust focused.

[phickey]

> WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world

The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.

> These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient.

The Bytecode Alliance has made big improvements to SpiderMonkey performance on WASM/WASI systems, and has work in progress to take advantage of SpiderMonkey's "native" codegen targeting WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We targeted JS first for this work because it is the most popular language with our customers and users, but we expect that this will show the path to adding similar improvements to Ruby, Python, and other languages commonly thought of as "interpreted".