I am not hung up on immutable collections, but it was interesting trying to practice that for a while. If you are dealing with things like actors, for example, then immutable collections are not necessary because there can be no concurrent access.

I am also a BIG fan of non-blocking concurrent collections that make use of TAS and CAS.

LOL - you mean Scala has bugs?

scalac is so broken that there are areas of it that nobody understands

No wonder Martin thought "Screw this, I'm going to start working on a brand new language"

Kotlin's

Sequences

cover lazy evaluation in much the same was as Scala's views and of course there's the usual

filter

,

map

and friends. Kotlin's heavy (and explicit) use of inlining also means lower overheads for such operations.

He claimed Dotty would be a smaller, less feature rich language, but when I read they kept

implicit

in, all I could do was shake my head.

The syntactic surface area is much smaller. His mistake is thinking that this logically implies the semantic surface area is smaller as well. It's not.

Excellent point

None of this matters anyway because Dotty (just like Scala) is just an engine designed to generate research papers.

And flowing from this, generate additional funding for EPFL.

Fair enough, we learned a lot from Scala.

Absolutely.

We learned what works and what doesn't.

James Gosling talked about the 'Kitchen Sink' language as a place to experiment, and I think he was correct.

I remain convinced that Scala is to Java what C++ is to C

I tried to make that case years ago and got beaten up for it.

Not sure if this is the best place for this conversation.

But back to the library, the stdlib that comes with a language has a huge effect on the language itself.

If Kotlin chooses to build upon the Java stdlib, then I would expect it to simply use the Kotlin language to make Java collections easier to use.

If Kotlin chose to create a new collections library, then I would expect it to do something really nice, cognisant of the lessons learned from Scala.

I don't know enough yet to advocate either way.

For example, in Scala,

Traversable

is a really nice way to utilize the Java

walkFileTree

utility. There is no equivalent to

Traversable

in Kotlin. In a way it makes sense that Kotlin implements its own

fileTreeWalk

instead. Science is about understanding how things work. Engineering is understanding about the compromises necessary to make things work.

I was always curious to see if Paul finished his own collections library as he threatened.

Doubt it

He's still using Scala as far as I can tell but you can tell he's not happy about it

@eric.kolotyluk: not sure I see your point, but Kotlin is about to be 1.0, which means it has chosen the collection design and there is no way to change it in stdlib

All improvements come as 3-party libs

BTW, old kotlin docs were there: https://confluence.jetbrains.com/display/Kotlin/Welcome @orangy, @ilya.gorbunov: where are they now? they were really useful to the justification for things (in the comments especially )

old docs are gone