The world of WebAssembly (Wasm) runtimes has evolved quickly over the last couple of years. In this short update, we'll cover the factors that drove us to transition to Wasmtime as the most natural choice to underpin wasmCloud.
As part of the continued effort to align wasmCloud with WASI standards and the component model, we've made a considered shift to Wasmtime for a couple of important reasons. Firsly, Wasmtime lives at the cutting edge of the Wasm ecosystem. It is the runtime used in a slew of major projects, and has been adopted by Shopify, Fastly, Fermyon, Microsoft, and more. We're incredibly lucky to be able to participate with them as our friends and teammates in the Bytecode Alliance, where the Wasmtime project is hosted.
With flexibility and choice in mind, we've also re-architected the way that we pull in Wasmtime so that we can use other types of runtimes that work well in tiny places. We haven't started that work yet, but we've been sure to design for it.
One of the coolest aspects of wasmCloud is we make it seamless to scale your application from cloud to edge. Of course, edge can mean a lot of different things. For us it means being able to run applications in a browser, on an IoT device, a phone, on your laptop and in multiple clouds -- anywhere, in fact.
As we push the boundaries of where Wasm applications can run, we see Wasmtime having the best support for a stable experience in these highly distributed environments. We're also evaluating alternative runtimes like WAMR, another engine coming out of the Bytecode Alliance.
The second reason we've migrated to Wasmtime is its stringent, audited security release process. Community members across the Bytecode Alliance are collaborating to give Wasmtime a credible and compliant security posture. With the community galvanized around this project, we're confident Wasmtime will become one of the foundational parts of all server-side Wasm initiatives in the future.
As part of the migration we were also able to quickly add an experimental flag for supporting the component model. Being able to prime Wasmtime for components will provide the assurances developers need that Wasmtime aligns with our new standards.
Finally, our decision to support Wasmtime supports our aspiration to drive multi-language support in wasmCloud. With Wit we can support open interfaces, which allows us true language interoperability on our platform -- something many of you are waiting for. What this comes down to is using a runtime that can support these developments: that's why Wasmtime makes so much sense. This is a fundamental part of the WASI stack -- the excitement coming from the community will drive experimentation, cool, fresh features and even better security.
Over the last year of developing wasmCloud in Elixir/OTP, we've learned a ton about the interoperability between Elixir and Rust. We've now moved to putting our Wasm host functionality in a common library libwasmcloud for better reuse across languages. We couldn't have done what we did without the help of Tessi, the maintainer of the open source project Wasmex, which now also supports Wasmtime as its underlying engine.
WASI standards and the component model are evolving at a rapid pace. To keep up with the latest developments, join the Bytecode Alliance Community and join our monthly meetings.
Join the conversation on Slack and get in touch! We're keen to hear your views.