I have been a full-time go developer since 2015 and I have quite literally never written a line of generic go code. I can't even recall seeing any written at any {job} since they've been introduced...

People like to blame Java for enterprise code, except they forget enterprise has been writing enterprisy code since Fortran, COBOL and Lisp days.

I have found Spring like magic with pre-processor macros, sed and awk, in the glory days of Yourdon Structured Method and enterprisy C code.

I remember my coworkers having managed to write Java in pre-generics Go. The code had functions wrapped in functions wrapped in yet more functions, and interfaces only ever implemented by one type to replace the generics abuse. Life finds a way.

> inherited from 10 levels of parent classes

This is not (yet) a thing in Go. Go does not have classes and inheritance. Interface is more like duck-typing.

"people working actively in "modern" Go codebases with generics, is it becoming like a Java/Spring kind of codebase?"

I have yet to encounter a 3rd party library that uses generics that isn't a data structure library of some sort. The only person I have seen doing crazy things with generics is... me. In my own code, for the most part [1]. In general I don't even see generics that are so much as parameterized by a meaningful interface like "type BlahBlah[R io.Reader]"; generics are so often parameterized by "any" that a casual reader might be forgiven for thinking that that is all a Go generic can do. As is often the case, the most complicated generic type signatures are the one in the standard library and even they aren't really all that bad, it's really just about the "~" operator allowing support for "all types that are either 'string' or something of the form 'type X string'".

I see the occasional person complain about how generics have ruined Go by making them too complicated. I push back on them with basically the previous paragraph. None of them have ever replied to press their point any farther. I interpret this to mean that their experience with the feature is in fact the same. At this point if you're buried in super complicated generics it is almost certainly someone on your own team and you should tell them to stop.

Similarly for iterators, by the way. The way Go did iterators is a bit odd to implement them yourself. Won't deny that. But it does compile down very efficiently, and only matters to the people writing the iterator not the consumer. Anyone who claims it has wrecked the language is invited to explain to me why it is that they are writing so many dozens of iterators all the time first, because as near as I can tell they aren't getting that from 3rd party libraries or the standard library.

[1]: The exception being https://github.com/thejerf/mtmap if you want to see something that I did find a use for, and you may have a use for, but is not something I would suggest using all the time. Very specific use case I had.

I’ve written generic code once or twice per year. Usage through libraries is higher, though it’s not very visible.

Rust has had generics for 10 years and doesn't have this problem. I think it's more a culture problem in Java than anything (and arguably a historical one).

I haven't seen that in the large codebase at work, for what it's worth. The thing that's surprised me about generics in Go is how rarely they're needed in practice. Very nice to have in the right place, but the vast majority of our source files still get along fine with plain old typed maps and slices.

I think Go is more commonly used in modern microservice architectures rather than in older monolithic architectures where the kind of Java code you're describing happens. Might have some impact on the level of complexity that can get out of hand.

In the Go codebases I have worked on, generics were not overused IMHO. It did allow us to get rid of some type specific helper functions and made collection based operations like sorting a lot nicer to work with.