undefined | Better HN

0 pointsmatei_radu2y ago0 comments

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) 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), 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), 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) and Java / TeaVM (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!

0 comments

rockwotj2y ago

I'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), 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?

konsoletyper2y ago

Why you guys keep using this old non-maintained fork of TeaVM, while there's WASI support in main TeaVM (https://github.com/konsoletyper/teavm)?

matei_raduOP2y ago

Joel from our team worked on the initial prototype for WASI support in TeaVM (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!

evntdrvn2y ago

yeah Steve Sanderson is a force :)

j / k navigate · click thread line to collapse