Go SDK V2 built on sdk-core

[yuandrew]

We are starting to consider/prototype a Go v2 that will be built on core, would love to hear any feedback on things users would like to see in this new SDK, like pain points in the current Go SDK.

Please feel free to suggest features for v2, as well as upvote features suggested by others to help us get a better sense of what users are looking for.

[cretz]

Few things (some copied from Slack):

• Generics, especially method generics
• Please avoid CGo, it is a nightmare at build time
  • There are dylib/so/dll approaches, but they are a delivery nightmare (Go does not make it easy to ship additional things w/ the project, go:embed would be bad here IMO)
  • There are wasm/wazero approaches, but probably requires some core rework
  • Overall, just keep in mind regular developers that love Go's fast build time, easy import, and nothing-besides-go-toolchain-needed approach
• There are many use cases for gRPC interception, don't be too eager to toss it (but may need to)

[mrsimonemms]

A Go-idiomatic composable constructor. Something like:

// Everything driven by provided options
c, err := temporal.NewConnection(
    temporal.WithHostPort("host.temporal.svc.cluster.local:7233"),
    temporal.WithTLS(true),
)

// Takes values from envvars, with override options
c, err := temporal.NewConnectionWithEnvvars()

I have already published this as a library, but making this the default would be useful.

[Quinn-With-Two-Ns]

The Functional Options pattern is certainly something we have considered, but so far the lack of visibility and the verbosity has kept us from using this pattern in the Go SDK. Recent Go changes like inferred composite literals also make the more standard struct approach of struct options even easier for users as well.

[Quinn-With-Two-Ns]

Seeing a few comments here and on Slack about cgo. Just for transparency we are evaluating a few different options when it comes to using Core with Go without CGo including:

• Using purego and embedding core for distribution.
• Using proposal: cmd/cgo: cgo without a C toolchain golang/go#81450 if it is accepted. Though this may technically still be cgo it would not require a C compiler or linker and should remove most of the operational pain of cgo. Distribution is also unclear here.
• Compiling Core to wasm and using wazero. This would require non trivial changes to our Rust core.
• Compiling Core to wasm and using a tool like wasm2go.