The promise of WebAssembly lies in its ability to deploy modules, so that code written in any programming language can be compiled into a WebAssembly module and distributed in binary format to any CPU device that executes its instruction sets. This means that developers can write in the language of their choice, compile into WebAssembly, and deploy to thousands of devices with a single click – whether servers, edge devices, or any CPU-based system.

Although WebAssembly has worked exceptionally well in the browser so far, the wider adoption of this technology is still evolving. Languages ​​such as C++ and Rust are particularly well suited to WebAssembly, but they lack one of the most important and accessible languages: Go.

Thanks to the WASI component model and significant advances in Go, especially TinyGo, it is now possible to use Go in the WebAssembly context and deploy it to WASI-compliant modules. Go currently relies on TinyGo for compilation, and this dependency will likely continue, but this is not necessarily a disadvantage.

For anyone looking to use WebAssembly with Go, this is a major milestone. The integration works, or at least it’s proven, and delivers on WebAssembly’s promise of broader support for different programming languages ​​on all devices beyond the browser.

Significant effort has been put into developing the Go bindings that allow Go to integrate and interact with TinyGo’s libraries for seamless functionality. As mentioned earlier, TinyGo is mostly behind the scenes. The Wasm + Tools for Go project documentation states that the repository provides code to generate Go bindings for component model interfaces defined in WebAssembly Interface Type (WIT) files. The goal of this project is to accelerate the adoption of the component model and the development of WASI 0.2+ in Go.

“Before this release, Go developers wrote Wasm apps, but now they can write Go apps and convert them to Wasm by just hitting a compiler flag,” said Eric Gregory, senior technical editor at Cosmonic and maintainer of wasmCloud, who praised Fastly’s Randy Reddig in a blog post for his work on wasm-tools-go. “This shows how aligning to a common standard improves the experience of toolchains in native languages ​​because they can target a common ABI (Application Binary Interface). Developers can write normal Go code and get component interoperability ‘for free.’ With the toolchain, there is a frictionless, accelerated developer experience for components, and across different languages, these toolchains are now taking shape.”

By compiling Go + TinyGo to Wasm, developers can write their code in Go, with TinyGo supporting the required libraries for WebAssembly compilation. The WASI interfaces remain transparent. As Gregory showed in a blog post, code written in Go using the go-jq CLI can be compiled to the WASI component target using the following command: .

Source: Eric Gregory, senior technical editor at Cosmonic and maintainer of wasmCloud,

The created component can then be executed using WASI P2 compatible WebAssembly, as shown with Wasmtime:

TinyGo’s time

It looks like TinyGo will continue to support Go indefinitely. Go for WebAssembly alone still has limitations. TinyGo’s creator Ron Evans noted that while TinyGo covers the entire Go language, it uses a different compiler that is written in Go but also leverages LLVM. “Big Go,” as Evans describes it, does offer some WASM support, but with inherent limitations and drawbacks.

TinyGo’s binary size is significantly smaller than Go code, by a factor of seven to ten, Evans said. “More importantly, TinyGo paved the way for new features in WASM/WASI, such as the WASI component model,” he added.

In addition, the existence of a stable standard with production use “makes the difference here,” said Bailey Hayes, CTO at Cosmonic, co-chair of the WASI subgroup and director of the Bytecode Alliance’s technical steering committee. Interestingly, Go lacks a more flexible production cadence compared to TinyGo. “WASI P2 allows languages ​​to support it, and we’re seeing the benefit of that now,” Hayes said. “TinyGo operates on a rapid release cycle, whereas ‘big’ Go comes out twice a year. So this feature will be available in TinyGo first and is intended for the next timed release of Go.”

However, TinyGo can also shine on its own. During the Wasm I/O conference in Barcelona earlier this year, Evans showed that TinyGo for Wasm is undergoing substantial development, particularly with regard to its compatibility with the open source framework Mechanoid, a framework for WebAssembly applications on embedded systems and IoT devices.

Component history

A WebAssembly component is critical for providing runtimes within WebAssembly modules, but its standardization is still in progress.

Once completed, the component model will also allow WebAssembly to extend beyond web browsers and servers. Using the WebAssembly System Interface (WASI), users can deploy various applications in lightweight modules at high speed to thousands of endpoints simultaneously, without changing a single line of code.

This model is often compared to Lego bricks, where components interface through WASI and allow WebAssembly modules to provide runtimes. These components can be stacked and linked to combine the versatility and power of different WebAssembly runtimes into a unified package or unit.

The ability to port Go code into WebAssembly modules will likely improve support for other languages ​​like Python for AI, thanks to ongoing Wasi P2 development. According to Hayes, compiling Go into Wasm components was challenging before new APIs and semantics were introduced in WASI P2.

“Developing an SDK that natively supports WASI P2 will benefit all languages, not just Go,” said Hayes. “We’re excited to see that, in addition to Rust and .NET, Golang now offers native support.”

And the work continues. “Language libraries and toolchains commit to multi-year support, so implementing changes at this level requires a high level of stability and commitment,” Hayes said. “The component model standard was introduced in January of this year, so it’s pretty exciting that standard language toolchains are already aligning with it and being able to build a component as a default compilation target.”

BC Gain is founder and senior analyst at ReveCom Media. His computer obsession began when he hacked a Space Invaders console in the early 1980s to play all day at the local video arcade for 25 cents. Then…

Read more from B. Cameron Gain