HKTs are something like generics for generics, so no.

E.g. a method takes some input and returns some output that is a list can have integers or strings, so you use generics instead of the concrete type integer/string.

But what if your input type is not a list of CONCRETE_TYPE but instead a WRAPPER_TYPE of CONCRETE_TYPE? E.g. say you have a method that can sort not only lists but also sets or trees, where each of these collections can contain an arbitrary (but comparable) concrete type like integer or string.

This WRAPPER_TYPE which can be parametrized with one or more other types (either concrete types or other wrapper types of arbitrary shapes) encapsulates the concept of a higher kinded type (where a simple type like integer or string would be a low-kinded type in this lingo).

In that case, basic generics are unfortunately not sufficient to express this.

In practice this is used mostly in libraries by library authors to provide users flexibility. It is especially helpful to help with compatibility between libraries that don't know of each other in advance. But it is also very useful for application developers to model different implementations of services/abstractions that have different properties.

Yep, thanks. Though, unfortunately, that's very far from what I can have in Scala. Maybe I'm wrong but seems like that I can't express even basic primitives like functor or monoid using this language. That's sad.