Spin 2.0 – open-source tool for building and running WASM apps
fermyon.comHi, everyone, I'm one of the Spin maintainers.
We're really excited about the new release, happy to answer questions about it!
Congrats on the release!
Question how did you come up with your the languages you support. Obviously how well the language compiles to Wasi is a factor, but how did you end up picking C# for instance?
Additionally how does Javascript support work? Are you embedding QuickJS?
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!
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?
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)?
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!
yeah Steve Sanderson is a force :)
Congrats on the release! Any example sites where Spin is in active use?
Thank you!
(disclaimer: I work at Fermyon, the company that created Spin.)
All of Fermyon's websites are powered by Spin, and there are quite a few users who are deploying their Spin applications to Fermyon Cloud.
While you advertise it as portable in the introduction the install guide only mentions "Linux (amd64 and arm64), macOS (Intel and Apple Silicon), and Windows (amd64)".
What are your plans on supporting more operating systems and architectures?
Thanks for the question!
Spin could definitely run in more places than what we have pre-built binaries for. Specifically, we could run on all platforms Wasmtime supports today (https://github.com/bytecodealliance/wasmtime/releases/tag/v1...), including RISC and S390X, for example.
And while we have been experimenting a bit with running Spin on RISC, we haven't really had the bandwidth or requirement to build a production build for those yet.
Are you interested in a specific operating system or CPU architecture? Would love to understand your scenario.
Hi Matei_Radu, Is it possible for spin to support actor-model pattern for eg. can it run long running process to execute trading strategies which will accept tick data every second
Hey, thanks for the question!
The short answer right now is no. The behavior of the default (and most popular) trigger in Spin (the HTTP trigger) is to create a new instance for handling each incoming request. We made that choice primarily because we want to leverage the really good startup times for Wasm (and in particular for Wasmtime), and not running any guest code (in this case, business logic) until there is an actual incoming request means the server can execute other applications while idle.
Now, HTTP workloads are not the only type of workloads that Spin can handle — because of the way it's built, it's entirely pluggable and you can build your own trigger (for example https://github.com/fermyon/spin-trigger-sqs), and potentially have long-running processes, but that is not currently possible with Spin today.
you can check out https://github.com/lunatic-solutions/lunatic for that
How to use Spin with Zig?
Hey, jesdict1!
Check out this community project that adds support for Zig — https://github.com/tensorush/zig-spin.
I still have to try wasm, but I see the main focus seems to be on cloud and edge deployments.
What I'd really like would be to program a game in C (or classic Turbo Pascal) and have a way to run it "hosted" in a iOS, Android or <whatever platform> native app. Is that possible nowadays?
You can compile the game to wasm and run it in a web environment. That can be a wrapper around a system webview, so you don't need to actually bundle a web engine in your app.
The web environment would provide all the API support for your game: graphics, audio, networking, etc. in a cross platform way.
This works today - many game engines compile to wasm, from Unity to Godot - but it is more popular to ship a native build of the engine on each platform rather than use a web environment. But that's because those engines take the time to port to each of those platforms; instead, you can use wasm + the web to get portability in a much simpler way (but with some limitations, of course).
I ported Neverball, a game written in C, to WASM (https://play.neverball.org/). It requires a browser to run, meaning it runs on any device that has a browser. That is superior to native in my eyes.
Someone would need to implement a library to abstract away the differences between all of these platforms, like Spin does for server software.
I'm not aware of a tech stack that does that.
I also replied to OP, but SDL is popular for this.
Not WASM-related, but just a few days ago we had a Cosmopolitan libc announcement on HN. https://news.ycombinator.com/item?id=38101613
This promises a single C code base and portable executable generation for
Linux MacOS Windows FreeBSD OpenBSD NetBSDYou could write it using SDL2, a popular C library. They say the support iOS and Android: https://wiki.libsdl.org/SDL2/Installation
you may want to take a look at https://github.com/extism/extism
Ahem? "Spin is a widely used open-source software verification tool"
and it's been around a long time
"The tool was developed at Bell Labs in the Unix group of the Computing Sciences Research Center, starting in 1980, and has been available freely since 1991"
I wonder if we’re at a point where it doesn’t really make sense anymore to insist on unique names. Most of the good ones have been used by now; and this likely won’t get better as more time passes.
It's a solved problem, and it's called trademark law / a wordmark.
Well it’s certainly not solved by trademark law for me, a lowly software engineer, trying to pick a rememberable name for my open source project that’ll maybe grow into something bigger someday.
If you’ve been through the process of naming something that is safe for trademark purposes then you might think we’re beyond unique names for things. We’re out of options.
Ha, naming is tough! At least it's not named Atlas :)
Allow me to introduce you to Watergate, our new dam simulation platform.
Very intriguing, great work and thanks for sharing!
Thank you for the kind words!
how can I call a js function from wasm?