people working actively in "modern" Go codebases with generics, is it becoming like a Java/Spring kind of codebase?
I understand why you might need generics, but I hate how Java ecosystem exploits it so much that, reading code becomes so difficult, because it was inherited from 10 levels of parent classes and in some cases Java Beans get created based on generic types and their parent classes are abstract classes.
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.
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.
> Go’s interface system works at runtime. The specific type of a value passed into an interface parameter is resolved while the program runs. This dynamic dispatch clashes with generics being resolved at compile time.
What if the compiler generated both vtable and monomorphized variants for each method? Most calls would use the static version but places that need it like interface generics call the virtual method.
Go is often thought of as a successor of C. C doesn't have methods, only global functions. From my perspective, Go added methods primarily so that you can use them in combination with interfaces. Given that interfaces don't support generic methods, I'm personally not convinced that this feature was worth adding.
> From my perspective, Go added methods primarily so that you can use them in combination with interfaces.
They also give you a limited form of overloading. Without methods or overloading, you end up in the situation that C and Scheme are in where every operation on a data structure has to redundantly have the data structure in its name like:
people working actively in "modern" Go codebases with generics, is it becoming like a Java/Spring kind of codebase?
I understand why you might need generics, but I hate how Java ecosystem exploits it so much that, reading code becomes so difficult, because it was inherited from 10 levels of parent classes and in some cases Java Beans get created based on generic types and their parent classes are abstract classes.
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.
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.
Entropy 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.
> Go’s interface system works at runtime. The specific type of a value passed into an interface parameter is resolved while the program runs. This dynamic dispatch clashes with generics being resolved at compile time.
What if the compiler generated both vtable and monomorphized variants for each method? Most calls would use the static version but places that need it like interface generics call the virtual method.
Go is often thought of as a successor of C. C doesn't have methods, only global functions. From my perspective, Go added methods primarily so that you can use them in combination with interfaces. Given that interfaces don't support generic methods, I'm personally not convinced that this feature was worth adding.
> From my perspective, Go added methods primarily so that you can use them in combination with interfaces.
They also give you a limited form of overloading. Without methods or overloading, you end up in the situation that C and Scheme are in where every operation on a data structure has to redundantly have the data structure in its name like:
What was the reason for interfaces having to work at runtime?