Q:

Kotlin and Immutable Collections?

I am learning Kotlin and it is looking likely I may want to use it as my primary language within the next year. However, I keep getting conflicting research that Kotlin does or does not have immutable collections and I'm trying to figure out if I need to use Google Guava. 
Can someone please give me some guidance on this? Does it by default use Immutable collections? What operators return mutable or immutable collections? If not, are there plans to implement them?

A:

Kotlin's List from the standard library is readonly:
interface List<out E> : Collection<E> (source)

A generic ordered collection of elements. Methods in this interface
  support only read-only access to the list; read/write access is
  supported through the MutableList interface.  
Parameters
  E - the type of elements contained in the list.

As mentioned, there is also the MutableList
interface MutableList<E> : List<E>, MutableCollection<E> (source)

A generic ordered collection of elements that supports adding and
  removing elements.  
Parameters
  E - the type of elements contained in the list.

Due to this, Kotlin enforces readonly behaviour through its interfaces, instead of throwing Exceptions on runtime like default Java implementations do.
Likewise, there is a MutableCollection, MutableIterable, MutableIterator, MutableListIterator, MutableMap, and MutableSet, see the stdlib documentation.

A:

It is confusing but there are three, not two types of immutability:

Mutable   - you are supposed to change the collection (Kotlin's MutableList)
Readonly - you are NOT supposed to change it (Kotlin's List) but something may (cast to Mutable, or change from Java)
Immutable - no one can change it (Guavas's immutable collections)

So in case (2) List is just an interface that does not have mutating methods, but you can change the instance if you cast it to MutableList.
With Guava (case (3)) you are safe from anybody to change the collection, even with a cast or from another thread.
Kotlin chose to be readonly in order to use Java collections directly, so there is no overhead or conversion in using Java collections..

A:

As you see in other answers, Kotlin has readonly interfaces to mutable collections that let you view a collection through a readonly lens.  But the collection can be bypassed via casting or manipulated from Java.  But in cooperative Kotlin code that is fine, most uses do not need truly immutable collections and if your team avoids casts to the mutable form of the collection then maybe you don't need fully immutable collections.
The Kotlin collections allow both copy-on-change mutations, as well as lazy mutations.  So to answer part of your questions, things like filter, map, flatmap, operators + - all create copies when used against non lazy collections.  When used on a Sequence they modify the values as the collection as it is accessed and continue to be lazy (resulting in another Sequence).  Although for a Sequence, calling anything such as toList, toSet, toMap will result in the final copy being made.  By naming convention almost anything that starts with to is making a copy. 
In other words, most operators return you the same type as you started with, and if that type is "readonly" then you will receive a copy.  If that type is lazy, then you will lazily apply the change until you demand the collection in its entirety.
Some people want them for other reasons, such as parallel processing.  In those cases, it might be best to look at really high performance collections designed just for those purposes.  And only use them in those cases, not in all general cases.  
In the JVM world it is hard to avoid interop with libraries that want standard Java collections, and converting to/from these collections adds a lot of pain and overhead for libraries that do not support the common interfaces.  Kotlin gives a good mix of interop and lack of conversion, with readonly protection by contract.
So if you can't avoid wanting immutable collections, Kotlin easily works with anything from the JVM space:

Guava (https://github.com/google/guava)
Dexx a port of the Scala collections to Java (https://github.com/andrewoma/dexx) with Kotlin helpers (https://github.com/andrewoma/dexx/blob/master/kollection/README.md)
Eclipse Collections (formerly GS-Collections) a really high performance, JDK compatible, top performer in parallel processing with immutable and mutable variations (home: https://www.eclipse.org/collections/ and Github: https://github.com/eclipse/eclipse-collections)
PCollections (http://pcollections.org/)

Also, the Kotlin team is working on Immutable Collections natively for Kotlin, that effort can be seen here: 
 https://github.com/Kotlin/kotlinx.collections.immutable
There are many other collection frameworks out there for all different needs and constraints, Google is your friend for finding them.  There is no reason the Kotlin team needs to reinvent them for its standard library.  You have a lot of options, and they specialize in different things such as performance, memory use, not-boxing, immutability, etc.  "Choice is Good"  ... therefore some others:  HPCC, HPCC-RT, FastUtil, Koloboke, Trove and more...
There are even efforts like Pure4J which since Kotlin supports Annotation processing now, maybe can have a port to Kotlin for similar ideals.

