-
-
Notifications
You must be signed in to change notification settings - Fork 730
[NEW FEATURE] WebAssembly scripting system #1729
Description
Hello! I'm a big fan of the Amethyst project, unfortunately I haven't had the opportunity to contribute yet.
I work at a company called Wasmer and we're making a server-side WebAssembly runtime. One of the neat uses of this is as a plugin system, being able to call WebAssembly functions from Rust and other languages and have the WebAssembly module call back into the host.
Description
This is less of a feature proposal and more of the start of a discussion around using WebAssembly as a scripting language. It's our goal to have Wasmer be very easy to use for these cases, but the Wasm ecosystem is still early on. Whether using Wasmer or not, Wasm plugins are a neat idea that I think will become very popular over the coming years.
What problem does this solve? What need does it fill?
Reasons why Wasm is useful as a scripting language:
- performance - Wasm JITs currently can run at near native speeds and we expect this to get better over time
- flexibility - use any language that compiles to Wasm; this is great for plugins created by users. It also opens up tons of libraries and the tooling of all these languages
- security - Wasm can be sandboxed and metered. It's simple to run untrusted code with limited resources and without worrying about it doing bad things (as of writing, metering works, but is still in development in Wasmer)
- standard - by using Wasm, you benefit from all the tools and work done on Wasm
- good plugin support - Wasm for plugins will likely become very popular and the tooling for connecting the pieces is coming together
Describe the solution you'd like
Feedback on the idea! Ideas about how to improve, what we'd need to support game engines well (we have some ideas already).
If you all are interested, we're interested in working with you to help design and implement this.
Describe alternatives you've considered
- special, endorsed scripting language(s) - probably more work, less flexible, less secure, etc.
- JVM - licensing issues with embedding, less ecosystem support, less flexible (Wasm explicitly supports running without garbage collection)
- no scripting languages - user-created content is awesome + dynamism is nice to have during development
- V8/other JS Wasm VMs - limited by the needs of JS, likely not as focused on plugin use-cases as Wasmer (Wasmer has being easily embeddable as a core design goal)
- Other non-JS Wasm VMs - You shouldn't trust what I say here because I'm clearly biased, but Wasmer is pretty good and has some useful features and is set up in such a way (technically and organizationally) that I think we'd be a good fit. Also if you use Wasmer then I'd be able to work on this during work 😄. Please do your own research here though and feel free to bring up any concerns!
Additional context
Known issues:
- compilation: eventually Wasmer will get tiering allowing for more optimized code to be generated over time, but currently you have to commit to a level of optimization up-front
- in-development-ness of Wasm - we'll have to wait a bit for threads, built-in GC, SIMD in Wasm, and things like that
PS:
I wrote this before seeing #271 ; Wasm support could be built on top of this, but I think a Wasm engine as the driver of a scripting system will be in-practice much simpler if safety, flexibility, and performance are the goals.