Both of the example things you picked are generic types, and container-esque types at that. I think that my opposition to generics in general is a scale of dislike for different uses of generics. So, an off the cuff scale from (well founded and acceptable in certain cases) to (a strict negative in nearly all cases) would be:

Polymorphic Types Parametricly Polynorphic functions ‘Well Motivated’ Ad-hoc Polymorphism Basic Function overloading Basic ‘Operator Overloading’ Function overloading for symbols that are treated as ‘special’ by the compiler

I think the hashmap case is illustrative for my general perspective. I do see the value in being able to have polymorphism for function arguments which are generic in a type parameter. However, consider that the ideal/most performant hashing function for keys differs not just based on general types (int vs string) but can differ based on something like string length or bit width or signededness. My position is that a language should prioritize the ability to encode those exact requirements in a data structure and difficulties for achieving generic-ness be damned. Each function taking a hashmap as argument should be tied to the optimizations and low level considerations intended by the developer.

I am not opposed to some duplication of code where it produces the appropriate code for the problem being solved. My generalized dislike of ‘generics’ is there, but in my comment above I was mostly discussing ad-hoc polymorphism as a means of enforcing some general reasoning ability onto function name overloading. And as I implied in my scale above I find it particularly distasteful (basic function name overloading), if not actively harmful.

For generics there are two areas often conflated in conversation that I find to be wildly different in formalizations of type theories and languages: first, there is static phase type application associated with System F and higher order polymorphic lambda calculus more broadly. I obviously would like to see a more specific and limited implementation of generics at all levels of abstraction, but the higher the abstraction goes the more ‘sense’ generic-ness makes. Second, there is generics as a name for function name overloading, which is distinct from parametricly polymorphic function as well as distinct from generic types. I really dislike this usage of generics and do not think it is a good practice for developing quality software or for readability, maintainability, or efficient optimization. Obviously this is a scale as well. I would put Swift in the lead with Witness Table semantics for generics, then typeclasses and traits, then any less structured implementations at the bottom.