Opportunity to share code?

[brendandburns]

Hey Folks,
I was pointed at this project. I have implemented much of an equivalent stack here:

https://github.com/dev-wasm/dev-wasm-go/tree/main/lib

Example usage:

• https://github.com/dev-wasm/dev-wasm-go/blob/main/http/main.go
• https://github.com/dev-wasm/dev-wasm-go/blob/main/webserver/wasi-http/main.go

I wonder if it makes sense to collaborate with each other on a single library binding for wasi + Go?

[ydnar]

Hey there. Happy to collaborate.

I started this repo in part for my and @Mossaka’s talk at WasmCon, and in part to learn/write a WASI adapter to Go stdlib semantics.

Time to chat in the coming days?

[brendandburns]

Yeah, you can reach me at bburns@microsoft.com to coordinate a time that works for both?

[ydnar]

@brendandburns I was able to spend more time on this repo in the last week, and ran into some ergonomics issues with cm.Option and cm.Result. I saw that you implemented some helpers for cm.Result in your repo, and wondering if you could comment on your experience with these types.

1. What criticisms or issues do you have with the existing cm.Option or cm.Result types, or generated code that uses these types?
2. What, if any, improvements would you suggest to these types to improve their ergonomics?

[ydnar]

This is now mostly working, albeit with the limitations inherent in WASI 0.2—no native streams, async, concurrency.

I see the promise of tighter integration between the Go runtime and underlying system primitives like async host calls, native streams, splicing streams to avoid copies, etc.