Go actor-authoring SDK: contribution proposal and runtime boundary

[erayack]

I'd like to contribute a Go SDK for authoring Rivet Actors: running the actor's handlers and state in Go, not just calling actors written in another language. I found the generated Go control-plane client, but haven't found a Go authoring SDK. Is one already planned or in progress?

I've been reading the Rust and TypeScript SDKs. The shared rivetkit-core looks like a possible reuse point for lifecycle and persistence, with the language adapter handling user code and state serialization. That raises a question: a Go adapter around the Rust core, or an independent Go runtime implementing the worker protocol?

I haven't verified either approach end to end, and don't want to assume the internal protocols are a supported boundary for another SDK. Before starting, I'd appreciate your direction:

• Would you prefer a shared-core adapter, accepting cgo and native-library packaging, or a pure Go runtime?
• Which SDK should be the behavioral reference, and which protocol or extension boundary should we target?
• Would a limited actor-authoring subset be useful initially? Are there conformance tests or fixtures we could reuse?

For a first prototype, I'm thinking of one counter actor called by an existing client, with an explicit durable save, worker restart recovery, and sleep/wake. I'd also test concurrent actions: a waiting action needs to be unblocked by another action, rather than locking the whole actor for each handler.

If you'd welcome this contribution, I'm happy to start with that limited scope and agree on the runtime boundary before proposing a broader Go API.