For instance Kotlin doesn't have reified generics (if I recall correctly they actually attempted it, but it's too hard to get it done on JVM), Kotlin doesn't have yield-return semantics, Kotlin's equivalent of LINQ doesn't use deferred evaluation. Kotlin doesn't have async/await like C#, which is a real gamechanger when it comes to asynchronous programming. It's very nice and promising, but it's not in the same league.
As far as JVM universe goes, Scala could give C# a better run for its money.
Of course it's not fair comparing Kotlin to C# - for numerous reasons - but if we do it anyway, it's got to be honest
Wow, I'm pretty surprised at that. Any kind of list comprehension/functional sub-language over collections seems like it ought to be deferred/lazy from the ground up. I'm doubly surprised at that from JetBrains.
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)
}
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
}
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
Easily? Proper implementation isn't so trivial, look what it takes for Guava:
https://code.google.com/p/guava-libraries/source/browse/guav...
https://code.google.com/p/google-collections/source/browse/t...
https://code.google.com/p/guava-libraries/source/browse/guav...
Plus:
* new (lazy) extension functions would be getting in the way of standard ones, you would need a paralel naming convention (perhaps one borrowed from LINQ, where map = select, filter = where, fold = aggregate and so on) and developers would still confuse one with another.
* unless we agree on one canonical implementation, yours would be different than mine, easy to see how it could become a mess.
If there is a better approach which removes these obstacles, someone let me know
For example, I ended up having to write Java code when dealing with large XML data sets in a Clojure system, because the current offerings simply didn't let me do what I needed in fluent Clojure code. I suspect Kotlin has those same kinds of issues, just amplified because it's a lot less widespread than Clojure.