Are you still at Fastly? Edge computing with WASI probably makes more sense as a niche for Go than browser WASM does. In the browser, every KB counts, so shipping a runtime is a disadvantage, but on the edge, a few extra MB is fine, as long as you can get fast start up times. So this could be very cool for something like Compute@Edge to use instead of being limited to TinyGo.
No, but I still hold an affinity for the space, as one of the last projects I worked on there was co-authoring fastly/compute-sdk-go, the TinyGo-based SDK for Compute@Edge. (Alas, that authorship lost to a squashed initial commit. C’est la vie.) Binary sizes in that environment were… important, but not critical to the point of optimizing at the KB layer, as you correctly point out.
And nothing but praise to the TinyGo team, who were very smart, responsive, and pleasant to work with. They immediately understood Wasi/Wasm as an important target architecture, which they definitely didn’t need to do, and we appreciated that. And in the end, what we wanted was not so difficult to do with TinyGo’s limitations. From a user perspective, the only big things missing versus “normal” Go were probably net/http and encoding/json. We re-wrote the former with most of the same idioms, which we would have needed to do anyway to work in our highly sandboxed Wasm execution environment, and there were some reasonable third-party alternatives for the latter.
This is cool and good.
Are you still at Fastly? Edge computing with WASI probably makes more sense as a niche for Go than browser WASM does. In the browser, every KB counts, so shipping a runtime is a disadvantage, but on the edge, a few extra MB is fine, as long as you can get fast start up times. So this could be very cool for something like Compute@Edge to use instead of being limited to TinyGo.
No, but I still hold an affinity for the space, as one of the last projects I worked on there was co-authoring fastly/compute-sdk-go, the TinyGo-based SDK for Compute@Edge. (Alas, that authorship lost to a squashed initial commit. C’est la vie.) Binary sizes in that environment were… important, but not critical to the point of optimizing at the KB layer, as you correctly point out.
And nothing but praise to the TinyGo team, who were very smart, responsive, and pleasant to work with. They immediately understood Wasi/Wasm as an important target architecture, which they definitely didn’t need to do, and we appreciated that. And in the end, what we wanted was not so difficult to do with TinyGo’s limitations. From a user perspective, the only big things missing versus “normal” Go were probably net/http and encoding/json. We re-wrote the former with most of the same idioms, which we would have needed to do anyway to work in our highly sandboxed Wasm execution environment, and there were some reasonable third-party alternatives for the latter.