bytecodealliance
Go bindgen todos
I would like to initiate a new tracking issue to categorize all the necessary steps in improving the Go bindgen experience. These steps will be divided into three categories: short-term, middle-term, and long-term. The duration of each term is not precisely defined at this point, but short-term goals would be tackled immediately after the merge of PR #471 into the main branch. Long-term goals are expected to be completed beyond 2023, while middle-term goals fall somewhere in between.
Short Term
- [ ] #528
- [x] #589
- [x] #615
- [ ] Go: Figure out utf16 string conversion from Go to C and vice versa. This will re-enable
tests/runtime/stringtests - [ ] Go: Use
Nsto create local variables to improve readable on the genereated Go code.
Middle Term
- [ ] #612
- [ ] #624
- [ ] #625
- [ ] #626
Long Term
- [ ] Go: change the TinyGo runtime to mainline Go compiler once it supports WASI target.
- [ ] #614
Performance-wise, I have done some rudimentary benchmark tests on a standard HTTP server that dispatches each HTTP request to a wasm component compiled from Rust and TinyGo. Here is the result:
Rust
TinyGo
You can see that the Rust compiled Wasm component's throughput is three times that of TinyGo. I suspect that the performance difference largely is contributed by the double copy of memory in type conversion between Go and C.
I've done some porting of the python component model MVP to pure go here: https://github.com/patrickhuber/go-wasm/tree/6015b8d07aaa1fc902fee44b01d1ebd6fded3d65/abi
More tests are needed for records, variants etc but strings and basic types are working.
I completed the unit tests suite included in the component model MVP. I'm going to try to replace some of the generated code with the go abi I created and see what challenges I run into. Latest here: https://github.com/patrickhuber/go-wasm/tree/main/abi