> If you use a lot of generic code in Java, you're going to really miss it in Go.
Doubt it, Go code has much less need for generics than Java code. This is in part because of Go's interfaces which cover some of the same space, because Go has builtin map and slice types, and because the general coding style in Go.
Have you really felt the need for generics when writing Go code? Because that is very, very rarely the case for me, and talking with many other Go programmers, the need for generics seems to very rarely come up when actually writing real world Go code.
One has to realize that features are not interchangeable across languages, just because they are essential to some language doesn't mean that they even make sense in another language.
I run into most issues when implementing datatypes like stacks/queues etc
It would be so much more beneficial to write one stack struct with associated methods rather than having to duplicate functionality for each type.
It's possible to use empty interfaces, but then you have to do runtime type assertions which defeats the point of static typing.
Maybe I've just been spoiled by Haskell/Java in that side of things, but I really feel that compile time static typing solves A LOT of development problems
Doubt it, Go code has much less need for generics than Java code. This is in part because of Go's interfaces which cover some of the same space, because Go has builtin map and slice types, and because the general coding style in Go.
Have you really felt the need for generics when writing Go code? Because that is very, very rarely the case for me, and talking with many other Go programmers, the need for generics seems to very rarely come up when actually writing real world Go code.
One has to realize that features are not interchangeable across languages, just because they are essential to some language doesn't mean that they even make sense in another language.