[mike_hearn]

Just to clarify, Kotlin doesn't have a collections library. What it does have is some clever compiler magic over JDK collections that adds:

• Mutable vs immutable views (List is read only, MutableList is read/write)

• Safer generics: map[key] which is translated to map.get() has the type bound you would expect rather than Java's much weaker Object type.

• Lots and lots of extension functions to do things like functional programming with them

However, behind the scenes they are still JDK collections, so you can call to and from existing Java with no problems and ... you know, actually, JDK collections library is pretty good. Especially once you get into the scalable concurrent collections.

[gecko]

Eh, I get why my phrasing might make it sound like they had a totally separate collections hierarchy; you're right, they don't. But I'd count the changes you list--especially the extension methods, which basically provide an entire Java 8-streams-like API that runs comfortably on top of even Android's superannuated Java--as a collections library in its own right. (Hell, even the fixes they do at the compiler level to maps makes the entire collections API feel a lot more like .NET, with its reified generics, and a lot less like Java's weird situation.)