A modern programming language that makes developers happier.

kotlinlang

Please, be careful what you wish for. We don't want Kotlin compiler (which is now written mostly in Kotlin and extensively uses Kotlin stdlib) to become slower than it is now, don't we? We actually plan to improve upon its performance. 

elizarov: wait, your insinuating that immutable collections are slower? My experience is the exact opposite, especially when you consider the GC thrashing that occurs when you combine an `ArrayList` with (Immutable) `List.plus`. I want a proper Immutable collection that maximizes sharing. this is one of my favourite talks on the subject: <https://www.infoq.com/presentations/Functional-Data-Structures-in-Scala>

Sure, they are faster than combining `ArrayList` with `List.plus` (why would anyone do this in performance-critical code?). I'm talking about their comparison with mutable data structures that you actually mutate (instead of rebuilding into new ones). The important datum to keep in mind is that most collection-manipulating code in real apps is read-only. You rarely modify maps and lists, but you query them a lot. Take Kotlin compiler, for example. It would build its a scope once and then query it many time while compiling the corresponding block of code. 

The worst part of the performance of persistent collections is that their query operations asymptotically (big O) and practically (even at small N) are much slower. The fact that you can efficiently combine them does not buy a lot in practice. Most practical algorithms (from data analysis to code compilation) become asymptotically slower when you express them in terms on persistent data structures. The cases where persistent data structure is a right choice from performance standpoint are extremely rare and niche. However, from thread-safety standpoint the decision to use persistent data structure is often a good one, because you gain simplicity and ease of reasoning about your concurrent code, despite loss of performance that is not important in many areas.

<@U2E974ELT> I would've thought that the number 1 consumer of a list is a for-each, which would make persistent vs mutable moot. Futher, according to that video I linked you a random-access to a bitmapped vector trie of 2 billion elements takes 7 array deferences, and is as fast as that random access into a `java.util.arraylist`.

Your point is of course perfectly valid on persistant domain models, because implementing sharing on those is a very difficult committment. But for collections, I feel like scala and clojure both have stunningly effective persistent implementations.

also

&gt; why would anyone do this in performance critical code 

because IIRC the current implementation of `listOf("one", "two") + "three"` would do this by default.