Unfortunately it is so, so I wouldn't recommend it for large collections, or wherever performance considerations come into equation.

Let's peek at Kotlin's sources (_Filtering.kt):

    public inline fun <T> Iterable<T>.filter(predicate: (T) -> Boolean): List<T> {
        // note how it's allocating a new ArrayList<T> - 
        // Kotlin doesn't have a "new" keyword, but it's initializing it here
        return filterTo(ArrayList<T>(), predicate)
    }

And it redirects to filterTo:

    public inline fun <T, C : MutableCollection<in T>> Iterable<T>.filterTo(destination: C, predicate: (T) -> Boolean): C {
        for (element in this) if (predicate(element)) destination.add(element)
        return destination
    }

With this approach, if you're chaining several of these operations, you will end up allocating quite a few arraylists, one by one.

Note that without something like yield-return in place, writing your own collection-transforming extension functions with lazy evaluation won't be so clean and easy either

Since it has 100% interop with Java, you could work around this problem by using something like Guava - Iterables and FluentIterable are based on iterators as they should.

They use static helper methods, all you need to do is to snap out some extension functions in Kotlin to serve as bindings to Guava. The only problem, especially on Android, is that Guava's notoriously big.

Kotlin is good, I'm not hating on it, but mature? Not yet. Nicer than C#? Best of luck, but not with this type of shortcomings