rfcs VS wit-bindgen

I think with Cranelift's investment into an e-graph based optimizer (https://github.com/bytecodealliance/rfcs/blob/main/accepted/cranelift-egraph.md) they are well positioned to have quite competitive performance as a backend.

They're also actively working in this area, for example the recently added equality saturation framework and the pattern matching DSL it builds on.

There's an RFC here: https://github.com/bytecodealliance/rfcs/pull/28 and Saúl Cabrera, the person who is leading this effort and implementing the compiler tier, has a work-in-progress draft PR here: https://github.com/bytecodealliance/wasmtime/pull/4907

We discussed that a bunch in the RFC: https://github.com/bytecodealliance/rfcs/pull/14 . The conclusion was, in short, that the current Wasmtime production users didn't yet require an LTS release process, and the maintenance of an LTS is pretty onerous, so we would come up with one in the future as those requirements become more clear: https://github.com/bytecodealliance/rfcs/pull/14#discussion\_r708638804

wit-bindgen-rust = { git = "https://github.com/bytecodealliance/wit-bindgen.git", rev = "60e3c5b41e616fee239304d92128e117dd9be0a7" }

Yep, you're right. For this, there are a few options. The ones most relevant to you are fp-bindgen, which targets Wasmer, and wit-bindgen, which targets wasmtime.

Yes, wasm_bindgen is js only. At least for now, in future I would also expect it to migrate to component model. There is also cargo-component which is a way to create modules compatible with component model. You define your module interface in WIT and your dependencies on other wasm modules in the similar way you would define crate dependencies. Alternately there is wit-bindgen that is a codegen tool for multiple languages that also accepts WIT as input.

Are you evaluating if WebAssembly Component Model, its WIT format and related tooling like wit-bindgen could be a good fit for your multiple languages support?

Our plan is to stick with both a Rust host and guest to begin with, and start developing other offerings as required. All of our bindings are implemented on top of wit-bindgen, which acts as our data transfer layer - as long as your guest language is supported by wit-bindgen, you'll be able to use the runtime in some form. (Our bindings make it nicer to use, though 😆)

[package] name = "sentiment" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] wit-bindgen-rust = { git = "https://github.com/bytecodealliance/wit-bindgen.git", rev = "60e3c5b41e616fee239304d92128e117dd9be0a7" } vader_sentiment = { git = "https://github.com/ckw017/vader-sentiment-rust" } lazy_static = "1.4.0" [lib] crate-type = ["cdylib"]

That is possible! Think wit-bindgen is something you should take a look at. With wit you can archive what you want :)

Wasmtime's `wasmtime-py` embedding in python has support for Wasm Components: https://github.com/bytecodealliance/wasmtime-py#components (disclosure, I helped create it)

The remaining piece of the puzzle would be to create a wit-bindgen guest generator https://github.com/bytecodealliance/wit-bindgen#guests for this build of the python interpreter. You could then seamlessly call back and forth between the host and guest pythons, without even knowing that wasmtime is under the hood.

Interesting little discussion linked about this fork of WAI from wit-bindgen:

https://github.com/bytecodealliance/wit-bindgen/issues/306

Is the interface defined through wit?

https://github.com/bytecodealliance/wit-bindgen