9 ms·

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 co

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.

Thaxll 2y ago
Go 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 ago
  I'm aware of the article's context but am asking the broader question.
  - boomskats 2y ago
    > I'm aware of the article's context but that just raises further questions. Why invest much effort, as a developer, or as a vendor, in a version of WASM that doesn't even let you run client side? It's carving an ever smaller niche. Because of the value it can deliver server-side, and that's where most of the value tends to be. Server-side compute is the core of most companies' revenue streams, yet it really is bloating out of control. Think about how much money is wasted on build pipelines, artifact storage, giant image distribution, multi-tenant workload isolation, supply chain risk mitigation; how expensive cloud infrastructure is, and what a substantial share of it is spent on all of those. With the way WASM was designed, it has the potential to completely upend all of it: tiny binaries, sandboxed runtimes, tightly knit mt, instant scaling, clearly defined contracts, language agnostic microservices. It's a completely different world. The potential for WASM in enterprise compute is immense - especially with the recent developments in the component model and WASI. We're talking about orders of magnitude improvements here.
    - pjmlp 2y ago
      Just wait until they figure out WASM Application Servers, using serialised WebAssembly for server to server messages, now that would be an idea.
      - boomskats 2y ago
        They could call it wRPC or something
        rvolosatovs 2y ago
        Funnily enough, that's what [wRPC](https://github.com/bytecodealliance/wrpc https://github.com/bytecodealliance/wrpc) is designed to do, using the small and efficient [Component Model Value Encoding](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Binary.md#-value-definitions https://github.com/WebAssembly/component-model/blob/main/des...), largely based on [Core Wasm spec](https://webassembly.github.io/spec/core/ https://webassembly.github.io/spec/core/). For example, here's an example of a Web App using [`wasi:keyvalue` interface](https://github.com/WebAssembly/wasi-keyvalue/ https://github.com/WebAssembly/wasi-keyvalue/) via WebTransport using wRPC: https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05810d8a5fa2b90a5f4e5b7fe871/examples/web https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05...
- pjmlp 2y ago
  And on that regard, there are more mature options out there, than reinventing the wheel with WebAssembly.
  - coder543 2y ago
    Do those "more mature" options support architecture-independent executables written in Rust or Go, so that a company doesn't need to rewrite their existing code in Java?
    - pjmlp 2y ago
      Well, depends if they target LLVM IR, or .NET MSIL. https://www.graalvm.org/latest/reference-manual/llvm/ https://www.graalvm.org/latest/reference-manual/llvm/ https://github.com/FractalFir/rustc_codegen_clr 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.
      - coder543 2y ago
        Containers are a much heavier way to implement a plug-in system, since you will also need to define an RPC of some kind, and they're not architecture-independent unless you require the users to build every container for every architecture. Containers generally aren't a security boundary, but you can wrap them in something like firecracker to help with that. (I believe plugins were an essential part of the context, based on the post we're commenting on, so it is important to evaluate these options against that.) LLVM IR as it is actually generated is also not architecture independent, and not a security boundary, making it a poor way to do a plugin system. Definitely not more mature for this type of stuff. .NET MSIL is probably a better fit than the other two options you provided, but not a good one... I don't think Go or Rust compile to MSIL, and MSIL probably isn't a very good security boundary anyways. I know from past discussions that you don't like WASM. I think you're overly dismissive of it. WASM has been around long enough now that it is a fairly mature system. I haven't personally needed it, but that's simply a comment on my own work experience, not the usefulness of the technology for specific use cases... and I can easily see why people are passionate about WASM. It's not NIH syndrome.
ratorx 2y ago
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.
bborud 2y ago
> 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.
- boomskats 2y ago
  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.
4ad 2y ago
> 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?".
LtWorf 2y ago
The use case is: "people who will waste days trying to not learn anything new". The entire idea o nodejs is that.
blog_nikajon_es 2y ago
> 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).
- hit8run 2y ago
  Sounds interesting. What context? How can I imagine this?
  - sleepybrett 2y ago
    istio supports wasm plugins: https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/ https://istio.io/latest/docs/reference/config/proxy_extensio...
9rx 2y ago
> 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.
- verst 2y ago
  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.
jerf 2y ago
"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 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.
- bloppe 2y ago
  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?
  - jerf 2y ago
    Well, "normal" Go binaries grow somewhat quickly as you add libraries. I don't think WASM is growing faster, it just stings more when you're looking at transferring them in realtime over a network. A 20MB binary is not really anything to a modern system, not even a Raspberry Pi. But a 4MB WASM executable can still hurt. (Though, sadly, only if you care. I just double-checked CNN's website, and given that it autostreams video it's hard to give a concrete "it took this much to load the site", but if I look at how much data was transferred before the home page stopped jumping around and rerendering and unblocking grey boxes and spinners, it was around 20MB.)
tylerflick 2y ago
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.
wjfuasdf 2y ago
> 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 https://github.com/golang/go/issues/71134

Thaxll 2y ago

Go 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 ago
I'm aware of the article's context but am asking the broader question.
- boomskats 2y ago
  > I'm aware of the article's context but that just raises further questions. Why invest much effort, as a developer, or as a vendor, in a version of WASM that doesn't even let you run client side? It's carving an ever smaller niche. Because of the value it can deliver server-side, and that's where most of the value tends to be. Server-side compute is the core of most companies' revenue streams, yet it really is bloating out of control. Think about how much money is wasted on build pipelines, artifact storage, giant image distribution, multi-tenant workload isolation, supply chain risk mitigation; how expensive cloud infrastructure is, and what a substantial share of it is spent on all of those. With the way WASM was designed, it has the potential to completely upend all of it: tiny binaries, sandboxed runtimes, tightly knit mt, instant scaling, clearly defined contracts, language agnostic microservices. It's a completely different world. The potential for WASM in enterprise compute is immense - especially with the recent developments in the component model and WASI. We're talking about orders of magnitude improvements here.
  - pjmlp 2y ago
    Just wait until they figure out WASM Application Servers, using serialised WebAssembly for server to server messages, now that would be an idea.
    - boomskats 2y ago
      They could call it wRPC or something
      - rvolosatovs 2y ago
        Funnily enough, that's what [wRPC](https://github.com/bytecodealliance/wrpc https://github.com/bytecodealliance/wrpc) is designed to do, using the small and efficient [Component Model Value Encoding](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Binary.md#-value-definitions https://github.com/WebAssembly/component-model/blob/main/des...), largely based on [Core Wasm spec](https://webassembly.github.io/spec/core/ https://webassembly.github.io/spec/core/). For example, here's an example of a Web App using [`wasi:keyvalue` interface](https://github.com/WebAssembly/wasi-keyvalue/ https://github.com/WebAssembly/wasi-keyvalue/) via WebTransport using wRPC: https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05810d8a5fa2b90a5f4e5b7fe871/examples/web https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05...
pjmlp 2y ago
And on that regard, there are more mature options out there, than reinventing the wheel with WebAssembly.
- coder543 2y ago
  Do those "more mature" options support architecture-independent executables written in Rust or Go, so that a company doesn't need to rewrite their existing code in Java?
  - pjmlp 2y ago
    Well, depends if they target LLVM IR, or .NET MSIL. https://www.graalvm.org/latest/reference-manual/llvm/ https://www.graalvm.org/latest/reference-manual/llvm/ https://github.com/FractalFir/rustc_codegen_clr 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.
    - coder543 2y ago
      Containers are a much heavier way to implement a plug-in system, since you will also need to define an RPC of some kind, and they're not architecture-independent unless you require the users to build every container for every architecture. Containers generally aren't a security boundary, but you can wrap them in something like firecracker to help with that. (I believe plugins were an essential part of the context, based on the post we're commenting on, so it is important to evaluate these options against that.) LLVM IR as it is actually generated is also not architecture independent, and not a security boundary, making it a poor way to do a plugin system. Definitely not more mature for this type of stuff. .NET MSIL is probably a better fit than the other two options you provided, but not a good one... I don't think Go or Rust compile to MSIL, and MSIL probably isn't a very good security boundary anyways. I know from past discussions that you don't like WASM. I think you're overly dismissive of it. WASM has been around long enough now that it is a fairly mature system. I haven't personally needed it, but that's simply a comment on my own work experience, not the usefulness of the technology for specific use cases... and I can easily see why people are passionate about WASM. It's not NIH syndrome.

ratorx 2y ago

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.

bborud 2y ago

> 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.

boomskats 2y ago
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.

4ad 2y ago

> 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?".

LtWorf 2y ago

The use case is: "people who will waste days trying to not learn anything new". The entire idea o nodejs is that.

blog_nikajon_es 2y ago

> 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).

hit8run 2y ago
Sounds interesting. What context? How can I imagine this?
- sleepybrett 2y ago
  istio supports wasm plugins: https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/ https://istio.io/latest/docs/reference/config/proxy_extensio...

9rx 2y ago

> 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.

verst 2y ago
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.

jerf 2y ago

"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 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.

bloppe 2y ago
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?
- jerf 2y ago
  Well, "normal" Go binaries grow somewhat quickly as you add libraries. I don't think WASM is growing faster, it just stings more when you're looking at transferring them in realtime over a network. A 20MB binary is not really anything to a modern system, not even a Raspberry Pi. But a 4MB WASM executable can still hurt. (Though, sadly, only if you care. I just double-checked CNN's website, and given that it autostreams video it's hard to give a concrete "it took this much to load the site", but if I look at how much data was transferred before the home page stopped jumping around and rerendering and unblocking grey boxes and spinners, it was around 20MB.)

tylerflick 2y ago

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.

wjfuasdf 2y ago

> 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 https://github.com/golang/go/issues/71134