The Internet Computer has officially supported writing canisters in Rust and Motoko for a while now. But the ecosystem has been expanding, with community efforts enabling smart contract development in other languages like C, JavaScript, and Python.
Recently, I’ve been experimenting with writing canisters in Go, and I’m excited to share that I’ve managed to get basic querying and updating functionality working through Candid interfaces! While Go isn’t officially supported, these early successes show promise for further exploration.
Why Go?
Go is known for its simplicity and efficiency. If we could make it a viable language for ICP canisters, it could open the door to a whole new group of developers who are already comfortable with the language. Plus, Go’s strong tooling and ecosystem could bring some unique advantages.
What Works So Far
Basic canisters in Go that can:
Expose Candid interfaces.
Handle query and update calls.
Successful interaction with the IC through DFX.
What’s Next?
Right now, the next logical step is to dive deeper:
Inter-canister calls: Enabling canisters written in Go to call other canisters.
Stable storage: Ensuring that data persists across upgrades.
Performance considerations: Understanding the trade-offs of using Go in this environment.
Interested?
I’d love to hear from you! If you think Go on ICP is worth pursuing, let me know. Should we explore inter-canister calls next? What other features would you want to see? Drop a comment or reach out, I’m open to collaboration!
As someone who has been working on Go tooling for ICP, I’m especially curious to see if there’s broader interest in pushing this further. Let’s discuss!
If you want developers to be stuck with really bloated, slow canisters then I guess this idea makes sense. I’m not happy with having Typescript compile to WASM, Go just seems like a waste of time especially with Caffeine and Motoko around the corner.
I know Go isn’t optimal for WASM, I use Rust both for writing canisters and for optimizing the Go WASM builds.
This is just me experimenting. No grand vision, just curiosity.
I literally did some research on this earlier today — not kidding. Not that I really want to give it a try since I have no knowledge of Go, but with Microsoft recently announcing that they rewrote TypeScript in Go, I had a hunch there might be some momentum in the web dev community to explore it. Long story short (and again, I’m not planning to try it myself, just as an outsider), but I think it’s pretty cool!
Side note: do you compile Go to WASI and then use wasi2ic, or what WASM target do you use?
Right now, I’m using TinyGo to compile to wasm-unknown, then sprinkling in some Rust magic afterward.
Planning to explore wasip1 as well, where wasi2ic will be useful.
Caffeine and Motoko are not silver bullets. If Rust introduces async, it also has a scheduling runtime. Motoko is a GC language, so these are not issues of Go - it just requires some optimization efforts when compiling to WASM.
Moreover, the WASM standard includes GC implementation. If GC languages can leverage this during WASM compilation, it could significantly reduce binary size. Additionally, when applications are designed with proper consideration for memory fragmentation optimization, the GC’s impact becomes far less significant than imagined.
From my personal experience of rewriting several C applications with Go, the code becomes several times more concise, performance improves multiplefold, and the memory safety plus maintainability benefits far exceed expectations. While I use Rust for writing canisters, I’m genuinely pleased to see developers working on Go-related initiatives in this space.
afterward.