Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding a WebAssembly interpreter as a host #119

Open
Sorseg opened this issue May 1, 2024 · 2 comments
Open

Consider adding a WebAssembly interpreter as a host #119

Sorseg opened this issue May 1, 2024 · 2 comments

Comments

@Sorseg
Copy link

Sorseg commented May 1, 2024

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:

  • the wasmtime dependency is quite large (45 seconds of compilation in an empty project from scratch on my ryzen 9 machine)
    • put it behind a feature flag or
    • seek for an alternative leaner implementation
  • the wasm component model, that includes the WIT seems to still being stabilized

Does this sound like a good idea to explore?
Thank you for developing this!

@makspll
Copy link
Owner

makspll commented May 1, 2024

Hey @Sorseg!

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.

@anlumo
Copy link

anlumo commented Oct 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants