Hi, everyone, I'm one of the Spin maintainers. We're really excited about the new release, happy to answer questions about it!
Spin 2.0 – open-source tool for building and running WASM apps
21–30 of 38 posts
Re: Spin 2.0 – open-source tool for building and running WASM apps
#22I 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 native app. Is that possible nowadays?
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.
Re: Spin 2.0 – open-source tool for building and running WASM apps
#23Earlier quoted context omitted.
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.
Re: Spin 2.0 – open-source tool for building and running WASM apps
#24Earlier quoted context omitted.
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 wi…
Re: Spin 2.0 – open-source tool for building and running WASM apps
#25Earlier quoted context omitted.
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.
Re: Spin 2.0 – open-source tool for building and running WASM apps
#26I 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 native app. Is that possible nowadays?
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).
Re: Spin 2.0 – open-source tool for building and running WASM apps
#27Earlier quoted context omitted.
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.
WASIX might come in handy for that! https://wasix.org
Re: Spin 2.0 – open-source tool for building and running WASM apps
#28Earlier quoted context omitted.
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 wi…
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?
Re: Spin 2.0 – open-source tool for building and running WASM apps
#29Hi, everyone, I'm one of the Spin maintainers. We're really excited about the new release, happy to answer questions about it!
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
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.
Re: Spin 2.0 – open-source tool for building and running WASM apps
#30I 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 native app. Is that possible nowadays?
This promises a single C code base and portable executable generation for
Linux
MacOS
Windows
FreeBSD
OpenBSD
NetBSD