Updates to the Go SDK - Questions, Feedback, Bug Fixes

[mnafees]

Hey everyone! 👋

We’ve just released a new version of the Go SDK as part of #2089.

We previously released the v1 Go SDK in April, but the initial feedback was that it was difficult to use, particularly with heavy reliance on generics. We felt that the feature clients were a step forward, but defining workflows and tasks were a step backwards. We took the opportunity when changing the package location to /sdks/go to make some major improvements to the Go SDK, in particular reducing reliance on generics.

📚 GoDoc: https://pkg.go.dev/github.com/hatchet-dev/hatchet/sdks/go

What the New /sdks/go SDK Accomplishes

No More Heavy Generics

The biggest change is removing the complex generic types everywhere. In the old SDK, you had to write workflow.WorkflowDeclaration[SimpleInput, SimpleResult] and create.WorkflowTask[DagInput, DagResult] with generics all over the place. The new SDK just uses simple functions like workflow.NewTask("name", func(ctx hatchet.Context, input MyStruct) (MyOutput, error)) - much cleaner and easier to read.

Simpler Workflow Creation

Creating workflows is now straightforward. Instead of the old factory.NewWorkflow[InputType, OutputType](create.WorkflowCreateOpts[InputType]{...}, hatchet), you just write client.NewWorkflow("my-workflow"). No more factory patterns or complex option structs for basic workflows.

Cleaner Task Dependencies

Setting up task dependencies is much simpler. The old SDK required you to define parents in the task options like create.WorkflowTask{Parents: []create.NamedTask{step1}}. Now you just add hatchet.WithParents(step1, step2) as a simple option when creating the task.

Direct Client Interface

Everything now starts from one client. Instead of getting a v1.HatchetClient and then using factories, you create hatchet.NewClient() and call methods directly on it like client.NewWorkflow() and client.NewWorker(). The API feels more natural and discoverable.

Go-Style Functional Options

The new SDK uses Go's standard functional options pattern with WithOption() functions. Instead of filling out big config structs, you can now write clean code like client.NewWorker("name", hatchet.WithWorkflows(wf1, wf2), hatchet.WithSlots(10)) or workflow.NewTask("task", fn, hatchet.WithRetries(3), hatchet.WithTimeout(30*time.Second)). This feels much more idiomatic to Go developers and makes the API self-documenting.

These changes make the SDK much easier to learn and use without sacrificing any functionality.

How you can contribute

1. Reply with the issue you’ve found, ideally with:
   • SDK version
   • Minimal code sample
   • Error output / unexpected behavior
2. Suggest potential fixes if you’ve explored them
3. Ask questions about intended usage or API design

💡 If your bug is big enough to deserve its own issue, feel free to open it in the repo — and link it back here so we can keep the conversation in sync.

We’re excited to hear your feedback and ideas — this is your chance to shape the SDK before it’s stable! 🚀

[johnlemon93]

Hi @mnafees,

First of all, thanks for this awesome improvement!
I took a close look and have one small feedback regarding the fn parameter in Workflow.NewTask. I think it's better to have the type back, instead of any, so we can shift the function signature validation to compile time instead of runtime.
Let me know if this makes sense.

[mnafees]

Hi @johnlemon93, given Go's generics system if we want to introduce compile-time checks for NewTask, it would require us to introduce generics in Workflow and in-turn into Client which we did in the older implementation of the Go SDK. Part of the reason to not depend on generics and instead use reflection is to keep the code tidy and readable.

[johnlemon93]

Got it now, I feel that we're facing an edge case that Go generic does not cover. Maybe having global registration functions that accept "client" as param could help to keep the type-safe with generic. But that still somewhat trades off the readability.

Hope that Go can improve its generic feature in the near future.