3 ms·

Nicer in what sense? I do like both, I'd take either of them over Java on any day, but whereas Kotlin is maybe better suited for functional style programming (i

by V-2 11y ago

Nicer in what sense? I do like both, I'd take either of them over Java on any day, but whereas Kotlin is maybe better suited for functional style programming (immutability out of the box, data classes etc. - however .NET people always have F# for this stuff), it's hardly on the same level as C#. 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

rjbwork 11y ago
>Kotlin's equivalent of LINQ doesn't use deferred evaluation. 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.
- weavie 11y ago
  I don't know much (anything..) about Kotlin, but surely that is a library issue and not a language issue - which could be quite easily rectified?
  - V-2 11y ago
    Yes and no... This is part of their standard library, so from a practical point of view, it is a language issue. Easily? Proper implementation isn't so trivial, look what it takes for Guava: https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/FluentIterable.java https://code.google.com/p/guava-libraries/source/browse/guav... https://code.google.com/p/google-collections/source/browse/trunk/src/com/google/common/collect/Iterables.java https://code.google.com/p/google-collections/source/browse/t... https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/Iterators.java 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
- V-2 11y ago
  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

by V-2 11y ago

rjbwork 11y ago

>Kotlin's equivalent of LINQ doesn't use deferred evaluation. 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.

weavie 11y ago
I don't know much (anything..) about Kotlin, but surely that is a library issue and not a language issue - which could be quite easily rectified?
- V-2 11y ago
  Yes and no... This is part of their standard library, so from a practical point of view, it is a language issue. Easily? Proper implementation isn't so trivial, look what it takes for Guava: https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/FluentIterable.java https://code.google.com/p/guava-libraries/source/browse/guav... https://code.google.com/p/google-collections/source/browse/trunk/src/com/google/common/collect/Iterables.java https://code.google.com/p/google-collections/source/browse/t... https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/Iterators.java 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
V-2 11y ago
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