As a bit of a counterpoint, I help maintain SDKs for Hatchet in multiple languages (largely Python and TS, but also contribute to Go a bit too) that benefit heavily from generics. It's especially useful for things where users of the SDK provide e.g. return types from functions they register, and we want those to be strongly-typed elsewhere in the codebase. A simple Python example is:

  @hatchet.task()
  async def my_task(...) -> SomeOutputType:
    return SomeOutputType(...)

  ## imagine this is an API handler:
  @api_handler("/some/path")
  async def handle() -> ...:
    result = await my_task.run(...)

    # we now know `result` is of type `SomeOutputType` without any sort of type assertion, etc.

Admittedly, I'm not a Go expert, nor am I a programming languages expert. But I do feel that this type of behavior is really only possible (with nice ergonomics) with generics, and it's always been upsetting to me that somehow Python's type system feels more complete than Go's in this arena, or at least it has until more recently.

Maybe this falls into the 1% of cases, but I'd suspect this sort of thing is more common than that.

Edit: I should have mentioned - in the Python example above, `@hatchet.task` is generic with the output type of the task it wraps.

I think you're right and it is sad to see. I think had they stuck to their guns, the language might not feel like it has lost the point.