You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding a WebAssembly interpreter, that supports the component model, for example the reference implementation wasmtime as a script host will allow using a bunch of languages for scripting (currently JavaScript, Python, Go) and quickly compiled and hot-reloaded rust.
Web assembly is definitely something I am interested in experimenting with. I haven't considered the idea of interpreting it!
I think this is definitely the approach I see as most compatible with this lib. Only issue I see is think we'd need to wait for the rust wasm interpreter to support the component model, but please correct me if I am wrong.
I am not familiar enough with WASM to tell if an effective script API would be plausible within vanilla WASM.
I would also wait for the Trait system overhaul PR #112 to merge (should be a few weeks) before developing this as it will make any sort of new integrations a million times simpler.
I've spent quite some time on wit recently, and the main issue I've run into is that it doesn’t allow data structures to be nested in themselves, similar to how in Rust an enum containing itself in one variant (like JSON lists containing JSON values, which can also be lists) would result in an infinitely sized type. However, Rust has a workaround by using Box<_>, there's no such thing in wit.
Also, there’s currently no implementation for components in the browser environment, which can be a problem or not, depending on the project. The Bytecode Alliance only supplies a converter from components to npm modules, which is kinda unusable for Rust projects.
Adding a WebAssembly interpreter, that supports the component model, for example the reference implementation wasmtime as a script host will allow using a bunch of languages for scripting (currently JavaScript, Python, Go) and quickly compiled and hot-reloaded rust.
WASM interface definition format also looks like a good fit to describe the scraped bevy API.
Downsides are:
Does this sound like a good idea to explore?
Thank you for developing this!
The text was updated successfully, but these errors were encountered: