Move Go SDK to use wit-bindgen 0.9

[rylev]

Resolves spinframework/spin-go-sdk#2 This is a not quite working move of the internals of the Go SDK to use wit-bindgen 0.8

Overall the move greatly simplifies things as we can stop using the C generator and move to direct tinygo support.

@Mossaka Here are a few bugs and usability issues I've found:

• FIXED: Alias anon types in tiny-go bytecodealliance/wit-bindgen#606 It seems the code generator does not follow use imports all the way through. When generating code for SDK I get some type errors because some definitions are not created: undefined: FermyonSpinHttpTypesTuple2StringStringT I have to add type aliases for these for them to work.
• FIXED: C: Namespace types inside of annoymous types bytecodealliance/wit-bindgen#608 Surprisingly I'm also getting errors in the generated C code. It seems like some error types are getting mixed up

sdk/go/generated/reactor.c:1404:22: error: assigning to 'fermyon_spin_redis_error_t' (aka 'unsigned char') from incompatible type 'fermyon_spin_key_value_error_t'
      result.val.err = variant;
                     ^ ~~~~~~~

• The Result and Option types are not the most helpful. Our SDK usually has return types of value, error and having to translate the Result and Option types to the (arguably more idiomatic) version is tedious. What speaks against the generated code following the value, error pattern more closely?
• Error types can't easily be turned into strings. Would it be possible to have some behavior like the Rust code generator which generates Display impls for error types?

I don't have time today to investigate the errors today, but I'll try to do so tomorrow. Let me know if you'd like to take a look together!

[Mossaka]

Thank you @rylev for using the the go-bindgen in Spin's Go SDK! These findings are great and insightful. It seems to me that the first two points are bugs, and the last two points are feature requests. I will raise each of them as an issue on the wit-bindgen repo and start working on fixing the bugs and improving the Result and Option type and the Error to String experience.

[adamreese]

Thanks for getting this work going. I too have found the Result and Option difficult to work with.

[rylev]

@Mossaka FYI: the other bug I'm seeing has been reproduced and logged as an issue here: bytecodealliance/wit-bindgen#607

[rylev]

This is blocked on one final issue: bytecodealliance/wit-bindgen#617. Once that issue is solved, this should be fine to merge.

[Mossaka]

Thank you, @rylev !!

[Mossaka]

This is blocked on one final issue: bytecodealliance/wit-bindgen#617.

Hey @rylev, could you please elaborate more about how this particular issue is blocking this PR?

[rylev]

Concretely, bytecodealliance/wit-bindgen#617 is about adding wit information including the metadata (e.g., the module "producer") to the component model so that tooling knows what the wit would the component targets. In spin-componentize (which is used to turn the plain core WebAssembly module the user builds into a WebAssembly component), we use the information encoded in this custom section to determine how to process the module.

If the module is produced with newer tooling, we know that we can just use the normal wit-component::ComponentEncoder to turn the module into a component. However, if older tooling was used we have to perform a bit of surgery to get the module into the right shape.

One thing I want to try now is to see can we just try to use the wit-component::ComponentEncoder to encode all modules and if it fails fallback to the hacks? I'm unsure if this will work, but it might?

[rylev]

Going to close this for now. We still want to resolve spinframework/spin-go-sdk#2, but things have evolved sufficiently from the wit-bindgen 0.9 days that this PR is not going to get merged without starting over.