2 ms·
Thank you! To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular. Due to Spin's heavy u
by matei_radu 3y ago
Thank you!
To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular.
Due to Spin's heavy use of WASI and the component model, languages that have first party support in the WIT bindings generator (https://github.com/bytecodealliance/wit-bindgen https://github.com/bytecodealliance/wit-bindgen) are the easiest to implement, followed by languages that can be built on top of the support for those with first party support.
For example, the JavaScript support is built by embedding QuickJS (in particular, Shopify's Javy project — https://github.com/fermyon/spin-js-sdk https://github.com/fermyon/spin-js-sdk), which then uses the Rust SDK.
(As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have significant experience) and JCO (https://github.com/bytecodealliance/jco https://github.com/bytecodealliance/jco), and the web platform compatibility makes it a significantly better proposition for things like 3rd party dependencies).
C# is an interesting one — the .NET team at Microsoft (and in particular Steve Sanderson from that team) has been making tremendous progress in ahead-of-time compilation for .NET and generating Wasm and WASI compatible binaries (as opposed to their initial approach on Blazor), and experimenting with that led us to build support for Spin as well.
Finally, we do a lot to support other popular languages and their Wasm support — two examples: Python (https://github.com/bytecodealliance/componentize-py https://github.com/bytecodealliance/componentize-py) and Java / TeaVM (https://github.com/fermyon/teavm-wasi https://github.com/fermyon/teavm-wasi), for which we haven't fully integrated Spin support, but we hope to get there soon.
I hope this explains a bit our process on language support, happy to expand on any point here.
Enjoy your weekend!
- evntdrvn 3y agoyeah Steve Sanderson is a force :)
- rockwotj 3y agoI'm impressed you're already leveraging the component model. I thought it wasn't quite ready for primetime yet, but it seems you're proving that wrong... I'll have to dig in more here, as I'm working embedding WebAssembly in a high performance storage engine. Thanks for the notes! I hear you on QuickJS - I've seen approaches of folks trying to build more node compatibility on top of quickjs (ala https://github.com/second-state/wasmedge-quickjs https://github.com/second-state/wasmedge-quickjs), but have recently heard about spidermonkey in wasmtime. Do you have intuition for nodejs vs browser in terms of what people want in terms of compatibility?
- konsoletyper 3y agoWhy you guys keep using this old non-maintained fork of TeaVM, while there's WASI support in main TeaVM (https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm)?
- matei_radu 3y agoJoel from our team worked on the initial prototype for WASI support in TeaVM (https://github.com/konsoletyper/teavm/pull/610 https://github.com/konsoletyper/teavm/pull/610), and we temporarily forked before the WASI support made it to the official repo. Good reminder to deprecate that now, and thanks for the amazing work on the project!