8 ms·
Extensible WASM Applications with Go
- euroderf 2y agoNo mention of working with the WASM component model.
- nilslice 2y agoof course not - Go has taste and appreciates quality and simplicity.
- jallasprit 2y agoFeel free to elaborate, because I have never heard about it either.
- boomskats 2y agoFrom 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/ https://wasi.dev/ [1]: https://component-model.bytecodealliance.org/ https://component-model.bytecodealliance.org/
- jcmfernandes 2y agoI thought that WASI and the component model were separate specs. Am I wrong?
- 4ad 2y agoWASIp2 implies component model. WASIp2 is implemented using component model.
- jcmfernandes 2y agoI 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 :(
- 4ad 2y agoAt some point Wazero will have to support component model, regardless of their opinion about it. Otherwise they will lose any relevance. But I agree with you, the tooling is very immature.
- nilslice 2y agono it will not. Wazero will likely never do that.
- 4ad 2y agoGreat, there are other Wasm runtimes to choose from.
- ncruces 2y agoIt's not just a matter of opinion, but resource allocation. WASI preview 1 was already a significant effort. It is the least polished bit of the wazero implementation, but even compared to: a spec compliant interpreter, two compilers and runtime, it weighs. It has some issues around filesystem sandboxing. And portability to “everywhere Go runs” is a pain. Preview 2 is a significant departure, with little promise that preview 3 isn't another, ad nauseam. For a small team, that's hard to track. Wasm 1.0 is a useful spec; Wasm 2.0 is still a draft. wazero supports everything final from 2.0 so far. WASIp1 was useful too, but wazero is useful without WASI. Until the dust settles, I'd rather wazero was reworked to make WASI even more pluggable from the outside (there are two impls already), than invest more resources in the WASI implementation itself. Still, if anyone wants to fund fulltime work on this, I guess that can be arranged.
- boomskats 2y agoCorrect, 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-2076284666 https://github.com/golang/go/issues/66984#issuecomment-20762...
- phickey 2y agoThis 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.
- boomskats 2y agoThis 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-2233660279 https://github.com/golang/go/issues/65333#issuecomment-22336...
- stpedgwdgfhgdd 2y agoA 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…
- zero_shift 2y agoI 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.
- Thaxll 2y agoGo binary size is not an issue, especially where the discussions is not related to browsers.
- deleted 2y ago[deleted]
- coder543 2y ago> 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.
- zero_shift 2y agoI'm aware of the article's context but am asking the broader question.
- Jyaif 2y agoHow do you debug WASM modules that are running in a host program?
- 4ad 2y agoPoorly. The tooling is very bad. But to be fair, this is not specific to Go.
- arccy 2y agothe one true debugging method: printf debug
- jitl 2y agoIn 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 https://developer.chrome.com/blog/wasm-debugging-2020
- smetannik 2y agoUnfortunately Go doesn’t support exporting DWARF for WASM atm, so printf is the only option. https://github.com/golang/go/issues/33503 https://github.com/golang/go/issues/33503
- amelius 2y agoHow does garbage collection work with Go and WASM?
- 4ad 2y agoJust the same as it works on amd64 or arm64 or any other architecture.
- amelius 2y agoYou mean inside another thread, collecting garbage concurrently? I'd be very surprised if it worked that way.
- marianoguerra 2y agonot 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.
- 4ad 2y agoNo, 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.
- thrance 2y agoI 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. [1] https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model
- 4ad 2y agoThe 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.
- nilslice 2y agoif 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.
- 4ad 2y agoPredicting 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.
- nilslice 2y agook. it’s on the brink of collapse. Bytecode Alliance is basically comprised of near-dead startups and one or two large corporates who do not care about it.
- 4ad 2y agoConsidering 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.
- donatj 2y agoSeems 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.
- Blackarea 2y agoIf there only was a low level language that came with strong typing and excellent wasm support...
- hu3 2y agoZig is great too. But different audiences imo.
- Blackarea 2y agoevery 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)?
- kodablah 2y agoAnd an excellent standard library with first class coroutine support and garbage collection?
- Blackarea 2y agolet's agree to have different tastes, my dear gentleman
- rs186 2y agoCompanies like Figma have been doing that for years.
- Blackarea 2y agodoing what?
- parasense 2y ago[flagged]
- tyho 2y agoUppercase for exported is actually one of my favorite go features. https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/go/types/object.go;l=77 https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/... https://www.compart.com/en/unicode/category/Lu https://www.compart.com/en/unicode/category/Lu there are plenty of non-latin scripts that have upper case letters.
- jimjimwii 2y agoI 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?
- kukiTsui 2y agoMoonBit looks like a promising language for WASM. They have WASM-GC and produce quite tiny code size. https://www.moonbitlang.com/ https://www.moonbitlang.com/
- uhindi3 2y ago[dead]