Most "complaints" about generics in Java have to do with type erasure. It's a tradeoff at the end of the day, it opened up the JVM to host many high quality languages like Scala, Kotlin, Clojure, etc. Haskell also does type erasure as far as I'm aware. Furthermore, the JVM is now getting generic specialization for value types, so types like HashMap<int, Object> become viable without the cost of boxing.
Inheritance based languages enable covariance and contravariance in generic types, something that comes in handy in many occasions.
“Haskell also does type erasure as far as I'm aware.” It’s not exactly an applicable term. Indeed Haskell doesn’t let runtime bother with a lot of information that it can provably dispense of. But there’s no laxity tradeoffs as in Java, Haskell won’t let you use a wrong type in a container
What actually matters is that you often _do_ have to cast at runtime in java, so it's somewhat common to hit type errors at runtime in practice. Haskell's type-system makes runtime type casting both less necessary, and vanishingly rare, meaning such runtime cases are practically never hit.
The above is at least true from my personal anecdotal experience.
As far as I know that unsoundness “hack” no longer work.
Hm, could you please show me where you had to cast? Long ago, some resource/service lookup did require casting, but my anecdotal experience is that there really is no common area where I have to cast anything anymore.
If a language erases all types, like Haskell, it's fine. If a language doesn't erase any types, like C#, it's fine. If a language erases types in some places but not others, like Java, you get all sorts of awful problems.
Inheritance based languages enable covariance and contravariance in generic types, something that comes in handy in many occasions.