A problem is that a Go produced WASM binary is really large. TinyGo overcomes this, but compiles too slow and you need to be really careful which libs to import (reflect). To overcome both, you need a lot of patience.
If you want to tryout Go WASM on Cloudflare workers you need to buy a subscription due to the size of the binary. Last time I tried you could run hello-world, but anything more substantial exceeded the size threshold.
Such a pity…
This is awesome. Something to keep in mind[0]:
> Remember that all the webassembly work in Go has been designed and implemented by volunteers, not the Go team, so timelines are dependent on availability of volunteers.
[0]: https://github.com/golang/go/issues/65333#issuecomment-22336...
Seems to me like it would have been more "Go" to simply export all functions starting with a capital letter in the main package, as exporting works normally in the language, only resorting to the compiler directive when you need to specifically name something starting with lowercase.
Apparently this is just copying the existing way cgo exports work. Fair enough I guess, prior art. The ergonomics are just a little outside the language as usual.
No mention of working with the WASM component model.
This addition unlocks the ability to use Go with the component model. The component model layers on top of Wasm Modules - a module which imports and exports functions with the component model ABI can be turned into a component using e.g. `wasm-tools component new`, and that transformation can include adapting wasip1 interfaces to wasip2. Without support for declaring export functions besides `main`, Go could only target the wasip2 CLI command world, but this enables it to target any component model world.
Correct, this looks like wasip1 support only for now. Discussion thread here[0].
Might be for the best, with wasip3 just around the corner.
[0]: https://github.com/golang/go/issues/66984#issuecomment-20762...
Feel free to elaborate, because I have never heard about it either.
From the wasi.dev[0] front page:
> WASI can be implemented by both core Wasm modules and applications built according to the Component Model, a specification for Wasm applications that are interoperable and composable. You can learn more about components in the Bytecode Alliance's WebAssembly Component Model documentation[1].
[0]: https://wasi.dev/ [1]: https://component-model.bytecodealliance.org/
I thought that WASI and the component model were separate specs. Am I wrong?
I see, thank you. I'm trying to get up to speed with the whole ecosystem as I have a use case for it. I would like to interact with WASM components from a go binary, but it seems like wazero doesn't and won't support the component model anytime soon. The rust tooling seems more mature ATM :(
of course not - Go has taste and appreciates quality and simplicity.
The WASM IDL for components (WIT) seems sleek enough.
its fine, I prefer ours more oriented around a familiar format like OpenAPI
I may be misremembering but wasn't it already possible to export go functions to js before go 1.24? I distinctly remember being able to call exported go functions in js without issues in prior. It would be really helpful if someone could explain to me how the new wasi niceties improve on what we had before (beyond supporting more types accross the ffi)?
Second question: it was possible for me to extract strings and other complex types from the wasm module's instance memory by casting pointers to integers, returning those integers to js, then using those values as an offset. If the binary representation of my types is guaranteed to be stable in go, is this method of passing pointers to js still viable for wasm modules produced when passing goos=wasip1?
MoonBit looks like a promising language for WASM. They have WASM-GC and produce quite tiny code size. https://www.moonbitlang.com/
How does garbage collection work with Go and WASM?
not sure what's the current status of Go so there are two alternatives:
if they are targeting Wasm pre Wasm-GC then they have to ship their GC in the Wasm module and it can't interoperate with "the outside world"
if they use Wasm-GC then they use the host's GC and values can be shared with the host and other guests.
No, Go can never use WasmGC because Go has interior pointers. Not even fat pointers help because Go has unboxed types.
Go will continue to use its own GC for the foreseeable future.
Interesting. Can it collect garbage _concurrently_ in WASM?
Last I checked WASM applications are single threaded, not sure if that's changed. GC is concurrent, but not parallelized.
Just the same as it works on amd64 or arm64 or any other architecture.
You mean inside another thread, collecting garbage concurrently? I'd be very surprised if it worked that way.
I am kind of worried that the eagerness for more WASM features may irremediably harm the young ecosystem. Most of what Go added to WASM could be done natively if the component model proposal [1] was merged already.
The standard evolves slowly and as adoption rises we risk having to support more and more non-standard features forever, like WASI and now this.
The component model is... part of WASI, so that criticism doesn't make any sense.
When Go adds support for WASI Preview 2 (or 3), it will have no choice but to support component model. The way WASI Preview 2 works is by making use of the component model.
if Go supports it. I do not believe it is likely. There will still be no native Go runtime to execute components. No one is using WASI p2.
Predicting things is hard, especially about the future, that being said, the people doing the Wasm work for Go want to move to the component model.
Considering the near complete overlap of people comprising the Bytecode Alliance with the people who created WebAssembly and people who maintain WebAssembly (especially the formal specification), I very much doubt that the Bytecode Alliance is in any sort of immediate danger. That said, you are right that corporations don't care about it, with some corporations even working against it.
do you need a disclaimer to your comments that you work on a product (XTP Bindgen) that is basically competing with the WASI component model? I don't care for either but thought the transparency was necessary.
How do you debug WASM modules that are running in a host program?
In v8 environments like browser or node, source maps work, so if you inject console.trace you can get printf debugging w/ legible stack traces on each log line, at least that’s my experience with c code compiled with Emscripten.
According to this 2020 blog post from Google, the Chrome debugger appears to have pretty full featured support for interactive debugging, although I’ve never needed to use it. https://developer.chrome.com/blog/wasm-debugging-2020
Unfortunately Go doesn’t support exporting DWARF for WASM atm, so printf is the only option.
the one true debugging method: printf debug
Poorly. The tooling is very bad. But to be fair, this is not specific to Go.
If there only was a low level language that came with strong typing and excellent wasm support...
And an excellent standard library with first class coroutine support and garbage collection?
let's agree to have different tastes, my dear gentleman
Zig is great too. But different audiences imo.
every language has a little bit different audiences. Haven't tried zig myself but I respect it (more than go... :D) and wanna check out some time - any recommendation to get an introduction (sth. like rust language book)?
Companies like Figma have been doing that for years.
doing what?
[dead]
[flagged]
Uppercase for exported is actually one of my favorite go features.
https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/...
https://www.compart.com/en/unicode/category/Lu
there are plenty of non-latin scripts that have upper case letters.
I guess my question is, why is Go compelling as a source language for WASM?
If I want to do high performance programming I don't want to worry about garbage collection.
If I can withstand GC then I know enough about JavaScript to keep V8's optimiser happy. Which will always be the best DX for writing code in the browser. (edit: though this post is specifically about WASI)
Go has never focused on binary size and probably never will unless it actually becomes an issue for Google. That's the disadvantage of having a corporate BDFL I guess.
"why is Go compelling as a source language for WASM?"
As near as I can tell, the answer is that it is supported, and has been working now for many versions.
See the short list of "production" languages here: https://github.com/appcypher/awesome-wasm-langs And read the sections carefully; you might think your $FAVORITE_LANG must be in the "stable for production usage" section given how big it is but it's full of a lot of languages with small communities. The really big names are mostly in the "unstable" category.
I can verify that I've toyed with some WASM support in a few languages now, and it is often not even functional, or takes vast effort to set up far above and beyond the official tutorials. You'll see a steady stream of stories on HN over the years about how this language or that language supports it, but in many cases those should be understood not so much as a commitment of support, but as a snapshot, that in that moment, it worked, but it may not work next week.
It's still true that Go produces big binaries. Official WASM garbage collection support may shrink that at some point though it'll still be larger than other languages for the goroutine runtime support. Not only is a bare minimum "Hello World" a couple of megabytes off the top, the Go WASM executables grow quickly as you add libraries. It rapidly becomes usable only for situations where you are guaranteed very high bandwidth for all users. Such situations exist, but is certainly a major limitation. (Though at least it does cache well, if you are even slightly careful with caching.)
So, to summarize, I'd say that it's not that Go is awesome and amazing, but that vast swathes of the competition are still quite bad.
Not true. I've built multiple production apps with Blazor WASM. Works great. Only drawback is the continually delayed multi threading support, but given native JS multi threading is far from ideal it's not a huge drawback.
I thought the runtime was essentially a fixed cost, and that a compiled Go binary would be similar in size to the native binary for the same source tree. Are you saying it grows faster?
laughs in kubectl
The most basic understanding of programming language runtimes is sufficient to guess the entire Production-tier list. There isn't any need to talk down to us about $FAVORITE_LANG
I strongly disagree. I'd expect it to me much larger by now, at least, based on my expectations and not my experience.
And once you clear the small-community languages out of the "stable" list I think it's underpopulated there as well; it's basically just .Net, .Net through C#, and .Net through F# (which I'm sure is more the .Net than the F#, no offense intended to the F# team). Way, way more of the languages I can name off the top of my head in "unstable" than I'd expect.
And while I don't intend this to be offensive to anyone either, WASM is just generally moving way slower than I expect. Given how many years that has been true at this point I must conclude it is being quite underinvested in, or, to put it another way, I'm blaming Google and peers for underinvesting, not the people working on it. More power to the people working on it, their skill is evident.
How did you miss: https://github.com/golang/go/issues/71134
How do you think?
> I guess my question is, why is Go compelling as a source language for WASM?
For me it is for three reasons: 1) I mostly write things in Go, 2) My main use-cases for WASM are backend applications, 3) being able to run sandboxed code (in backends) would be really, really useful.
Sadly, right now it is rather fiddly to make use of WASM in Go.
> If I want to do high performance programming I don't want to > worry about garbage collection
Then don't worry.
For most applications performance isn't going to be lost due to GC, but due to poor design choices and lack of effort. My observation is that most programmers tend to overestimate their own ability to routinely produce high performance code and under-estimate the cost of producing high performance code. The latter is more important. Writing high performance code (regardless of language/runtime) is time-consuming and tends to require a lot of skill to achieve consistently.
That being said, "high performance programming" is ill defined. For the term to have any real meaning one has to be more specific about what one tries to achieve.
> Go has never focused on binary size and probably never will unless > it actually becomes an issue for Google.
Probably correct. The problems of those who put in the work developing Go is probably going to receive priority. Binary size isn't a huge problem for the things people tend to use Go for.
As an aside; I've been writing software for an embedded Linux platform lately where binary size can become a challenge. I observed that the binaries produced by roughly equivalent C++ programs are about the same size as the Go binaries. Bigger if you take into account that the C++ programs were dynamically linked and the Go programs were statically linked. So your mileage may vary.
It may be that it is possible to introduce tooling and libraries that would allow you to generate WASM output that has a significantly smaller footprint.
> That's the disadvantage of having a corporate BDFL I guess.
No, I don't think it is tied to Google's ownership of Go. As with almost all large open source projects it is about developers and priorities. And a lot of open source gets developed on company time. If you want to help the Go project produce smaller WASM binaries then I don't see why Google would discourage you from contributing. If companies and people do not want to contribute it isn't going to get done.
What primarily brings you to using backend WASM rather than deploying Go natively?
My main "high performance" experience is of writing WebVR applications. VR can't tolerate framerate drops because it makes users physically sick.I don't know what the GC story is like for Go in WASM but it would make me very wary.
That's interesting.
How do you enforce a contract on these WASI artefacts? How do you stop the user doing bad things (like infinite loops or crashing the surrounding program)?
Well, now you have defined what you mean (realtime'ish execution low/no latency variance). The next step would be to formulate a test and see if it is actually a problem and then make technology choices. Just assuming isn't really professional.
You can always find use-cases where GC'ed languages might be challenging to use. With emphasis on "might", because you kind of have to try it out before you can determine if it is a problem.
There are a lot of high performance applications where they're just fine. For instance if you care more about throughput than latency variance. This is why "high performance" isn't a useful term. You have to be specific about how you measure "performance".
Most of the code for most developers isn't terribly performance critical. Correctness is usually far more important. Most performance tends to be lost due to lack of design talent rather than the language.
This is a great take, I agree 100%.
I'm curious, would you mind elaborating on your use-cases for sandboxed backend application code? This is clearly the direction in which it's all headed, yet is still mentioned relatively rarely in WASM-related discussions on here.
> I'm curious, would you mind elaborating on your use-cases for sandboxed backend application code?
When working with backend systems you generally have 2 choices, a less secure containerized environment that does a very good job of distributing resources or a bulky VM which has a fixed memory cost that you might not need.
WASM sits right in the middle of the two. It has a durable sandbox that prevents bugs in the application logic from exposing the whole machine to exploit (and it itself can be further isolated using the same containerization security practices) but also has the benefits of single app like resource requirements.
Another prime benefit of WASM (not related to the sandboxing) is that WASM is a write once run anywhere standard. That means you don't need a different x86 and ARM wasm deployable. Similar to Java's JAR.
Thanks, appreciate the response. I read your other answer too.
Given what you've just described, do you have an opinion on the component model & WIT[0]?
[0]: https://component-model.bytecodealliance.org/design/wit.html...
Check out Extism
why not just a slim podman?
Database stored procedures / user-defined functions written in arbitrary languages is a live use case on several platforms today.
> Which will always be the best DX for writing code in the browser.
The article we're all commenting on is not about running WASM in the browser.
WASI in particular may never be supported by browsers.
I'm aware of the article's context but am asking the broader question.
Just wait until they figure out WASM Application Servers, using serialised WebAssembly for server to server messages, now that would be an idea.
And on that regard, there are more mature options out there, than reinventing the wheel with WebAssembly.
Well, depends if they target LLVM IR, or .NET MSIL.
https://www.graalvm.org/latest/reference-manual/llvm/
https://github.com/FractalFir/rustc_codegen_clr
Also ever heard about containers?
They have this magic feature, you don't need to rewrite anything to run on servers.
.NET does support embedding:
- As full runtime i.e. hostfxr https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc... (supplementary: https://github.com/StudioCherno/Coral)
- As a dynamic library via DNNE with full runtime: https://github.com/AaronRobinsonMSFT/DNNE
- As either dynamic (easy) or static (hard) native library: https://github.com/dotnet/samples/tree/main/core/nativeaot/N...
There are a few community projects which build on top of these to provide a more seamless integration with other languages.
You can embed JVM with JNI_CreateJavaVM(): https://docs.oracle.com/javase/7/docs/technotes/guides/jni/s...
It is used used by projects like Postgres PL/Java, LibreOffice and various native Java launchers/wrappers
Dynamic libraries come to mind.
> Go has never focused on binary size and probably never will unless it actually becomes an issue for Google.
The Go project moved to being community directed quite a few years ago. The community hasn't shown it desperately needs smaller binaries either, though. It'd take them, I'm sure, but there are more important concerns.
> That's the disadvantage of having a corporate BDFL I guess.
Even if we, for the sake of discussion, assumed that Google still only specs the language for Google needs, there shouldn't be anything in the specification that necessitates large binaries. tinygo has shown that they can be small. And now that Microsoft has its own Go compiler, Google isn't the only deep pockets involved either. But so long as it is not seen as a pressing concern there isn't apt to be anyone to step up and put in the work to close the gaps.
The Microsoft Go distribution is a special build for FIPS 140-2 compliance (replacing some TLS / crypto libraries and such). I do not believe that there are plans to make any other changes here.
> why is Go compelling as a source language for WASM?
"Compelling" has nothing to do with it. People write Go code (or have already written it) and want to run in Wasm, just like they want to run it in any other environment. It's as simple as that.
Your question is equivalent to "why do people want to write Go?".
> I guess my question is, why is Go compelling as a source language for WASM?
I'm using WASM as a proper plugin architecture for some of my go applications. I provide an interface that allows external developers to create plugins (in whatever language supports WASM as a bonus). Then my application can then use these plugins to execute some extra functionality. It slows the application startup a little but runs pretty fast when in use, but I don't have plugins in any hot paths (yet).
Sounds interesting. What context? How can I imagine this?
istio supports wasm plugins: https://istio.io/latest/docs/reference/config/proxy_extensio...
I can think of a few (nothing super compelling though):
* “batteries-included” std - some of this is platform APIs, so only really the pure stuff. You can use all of this in the wasm extension, whereas you’d need to pull in deps for JS.
* Non-browser use cases (dynamic extensions, cross-platform “binaries”, cloud functions etc)
* probably the same reasons that JS/NodeJS became popular on the backend, but with roles reversed.
I used this in a previous role. The answer is, we had a server side solution that we wanted to make available on clients that had no internet connection. The logic was complex, and this allowed us to ship much faster.
> I guess my question is, why is Go compelling as a source language for WASM?
It's not currently: https://github.com/golang/go/issues/71134
Go binary size is not an issue, especially where the discussions is not related to browsers.
The use case is: "people who will waste days trying to not learn anything new".
The entire idea o nodejs is that.
Go is also a lot slower in wasm than non-gc languages due to its runtime requirements. I believe the wasm gc spec does not really help Go either so there won't be significant performance gains. It's a shame but it is what it is.
I have been playing with different languages in wasm and I settled on zig which does wasm pretty fine.
In practice, I've very rarely seen a downside: I compare it to something like Vite, where it uses esbuild in development and rollup in production, because the two libraries are for different things (esbuild doesn't bundle, rollup does, etc).
In development, I compile it with Go. In production, I compile it with TinyGo. Yes, you need to be careful about imports, and it does add complexity, but the benefits of not managing two different completely different languages (JS and whatever you're compiling to WASM) far outweigh that cost.
As for Cloudflare, I don't think their service's benefits outweigh the complexity, but I've had luck in the past with the dual setup on Workers.
ESBuild is a bundler. The subtitle on the website is literally “An extremely fast bundler for the web”. To bundle, pass —-bundle flag.
https://esbuild.github.io/
Yep! You're right, it does have the ability to bundle -- that's my bad. Rollup is just much better at bundling for production, just like TinyGo. Similarly, esbuild is better for development, just like Go.
A good rundown (rolldown) is available here: https://rolldown.rs/about
Agreed this is a big downside. It rules out go for websites (except maybe the biggest web “apps”) where load time isn’t important.
But being able to deploy a Go app to Cloudflare or other wasi runtimes is still really nice to have.
You can run the Go compiled wasm binary through wasm-opt (https://github.com/WebAssembly/binaryen) and it will decrease the size and give back some of the performance lost by using the standard go compiler over TinyGo. Fair warning it's pretty slow, and fun fact tinygo passes it's wasm files through wasm-opt which is why the tinygo compilation feels especially slow, I believe this can possibly be disabled via flag.