[Tea418]

The public Go code I usually read are libraries and I admit I also noticed only a little adoption of generics.

My personal hypothesis is that many libraries follow the official Go release policy[1]. Due to the fact that generics were introduced with v1.18 and we now have v1.19, libraries would be bound to the features that were available with v1.17, unless they spend effort on working around this by implementing the respective build flags that make generics available exclusively for >=v1.18. However this is just an assumption.

According to the Go Developer Survey 2022 Q2[2], 1 in 4 respondents said they've already started using generics in their Go code and 14% have started using generics in production code.

[1] https://go.dev/doc/devel/release [2] https://go.dev/blog/survey2022-q2-results

[evanelias]

The official Go release policy is to only support the 2 most recent versions, currently Go 1.18 and 1.19. So libraries can strictly follow this policy and use generics without any need for build flags.

That said, libraries often want to be friendly to older Go versions, so I agree with your overall hypothesis.

Backwards compatibility is another major concern for libraries: I assume you can't safely change the signatures of existing functions from interfaces to generics, for example. (Well, aside from some special cases like interface{} becoming "any".)

[Macha]

Honestly, 1 in 4 sounds pretty in line with Java and C# codebases which have a similiar conservative culture (assuming "using" = "writing generic classes/functions", and not consuming, which I think is a pretty safe assumption as Go already had generics for the consumer in the built in map/list/etc)

[Beltalowda]

Also: many libraries have little or no use for generics, and even if it's some benefit it's still worth asking if it's enough benefit for the added complexity (e.g. replacing "any" with generics is probably good; replacing "string" or "int" with generics: not always).

Also also: in quite a few cases switching to generics is a backwards-incompatible change or an "ugly" change (similar to Foo() and FooContext()), which makes adding them to existing libraries a bit painful.