Go sdk

[jgindin]

Description

Go SDK

This has been generated to match the features and
functionality of the Python SDK.

The Rizzcharts sample has also been regenerated in Go, using the Go SDK
as a demonstration.

Pre-launch Checklist

• I signed the CLA.
• I read the Contributors Guide.
• I read the Style Guide.
• I have added updates to the CHANGELOG.
• I updated/added relevant documentation.
• My code changes (if any) have tests.

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive Go SDK for A2UI, along with a sample agent implementation. The changes are well-structured and cover core SDK functionality, testing, and a practical usage example. My review focuses on improving code efficiency, robustness, and removing redundant or dead code. Key suggestions include optimizing type assertions, fixing a logging issue, enhancing type handling for tool parameters, and simplifying HTTP header processing.

[nan-yu]

Thanks for adding the Go SDK! The implementation looks great.

One suggestion regarding the rizzcharts example: I noticed that the JSON examples and catalog definitions are currently duplicated across the Go and Python samples. To keep things clean, could we move these into a shared peer folder that both samples can reference?

Also, just a heads-up that we are currently refactoring the Python SDK to include more common functionalities. Once those changes are finalized, we’ll likely need to consolidate the Go SDK to match.

[zeroasterisk]

Should this binary be submitted?

[jgindin]

Thanks for catching this.

[jacobsimionato]

I don’t know much about Go so I can’t offer an in depth review but this seems like a direct port of the Python agent utilities which sounds good!

I am curious about the roadmap here! Are you planning to depend on this library immediately in places other than the example? And are you planning to actively develop this code base?

We have a lot of changes ahead of us for the inference utilities with @nan-yu ‘s work to factor out and optimise common inference patterns, and an upcoming migration to the 0.9 spec. I think the most efficient way to do this is to do all front line development in one language (e.g. Python) and then port the changes to other languages (with a lot of agent help of course). Does that fit with your plans here? Maybe we can label this library as being explicitly a port of Python, and maybe we can just do another fresh port after 0.9 is implemented in Python rather than evolving this organically.