5 ms·

Which platform? For Android? Kotlin all the way. Servers? Java is much closer to the JVM and Kotlin is an abstraction over it which honestly does not provide

Which platform? For Android? Kotlin all the way. Servers? Java is much closer to the JVM and Kotlin is an abstraction over it which honestly does not provide much extra compared to Java 21. Kotlin has several design decisions which are neater 80% of time, but Java is the better general purpose language for those 20%. OC, much is a matter of taste. And in Kotlin will find yourself in awkward positions where you have to use Java Collections and you lose all the advantages of Kotlin (HashMaps not having non-nullable values is one of them).

adra 3y ago
All kotlin collection types are essentially Java ones (at least for a JVM target), the difference is that the IDE and compiler are smart about its type inference system so that it can tell when a variable use is nullable or not. Java has come a long way in recent years and it's far better than it was in the past. Kotlin stands on the great baseline of features that Java has established and there are certainly many advantages to (mostly ergonomics), to using Kotlin over Java at least for the time being.
dullcrisp 3y ago
> HashMaps not having non-nullable values Not sure about that example since it’s easy to do class MapWithDefault<K, V>( private val map: Map<K, V>, private val defaultValue: V ) { fun get(k: K) = map.get(k) ?: defaultValue // … } Edit: or I’m sure there’s something that does this already.
- DarkNova6 3y ago
  Still, this is not a first-class citizen in the Kotlin space, even-though you would assume it to be the case. Introducing such custom classes is always a little icky when working in a team.
- jayd16 3y ago
  It's probably about having to box value types.
eweise 3y ago
Java is still pretty ugly when you have to use the functions api https://docs.oracle.com/javase/8/docs/api/java/util/function/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/function.... I don't know why they can't make it like kotlin and scala where you just can just type the function definition instead of trying to find a class that represents what you want. This streams API for example, is unreadable. <R> R collect (Supplier<R> supplier, BiConsumer<R, ? super T> accumulator, BiConsumer<R, R> combiner)
- DarkNova6 3y ago
  I see the opposite. I think functional implementation of interfaces is lacking in Kotlin big time. The fact that you see a type like Comparable<T> and can implement it with an anonymous function is unique to Java. In other languages you would have Function<Int, T, T> which simply baffles the mind. Java has a powerful and performant model which also benefits from static and default methods (e.g. functional composition). Granted, the collect endpoint looks pretty wild but in 99% of cases you will simply use ".toList" or Collectors.toSet().
  - eweise 3y ago
    I just meant that its much nicer to read and write (T) -> R vs Function<T,R> Maybe Kotlin lacks implementing interfaces functionally but in practice, I can't remember it being a pain point. Funtional programming in Java to me, still feels very clunky compared to scala and kotlin.

adra 3y ago

All kotlin collection types are essentially Java ones (at least for a JVM target), the difference is that the IDE and compiler are smart about its type inference system so that it can tell when a variable use is nullable or not. Java has come a long way in recent years and it's far better than it was in the past. Kotlin stands on the great baseline of features that Java has established and there are certainly many advantages to (mostly ergonomics), to using Kotlin over Java at least for the time being.

dullcrisp 3y ago

> HashMaps not having non-nullable values Not sure about that example since it’s easy to do class MapWithDefault<K, V>( private val map: Map<K, V>, private val defaultValue: V ) { fun get(k: K) = map.get(k) ?: defaultValue // … } Edit: or I’m sure there’s something that does this already.

DarkNova6 3y ago
Still, this is not a first-class citizen in the Kotlin space, even-though you would assume it to be the case. Introducing such custom classes is always a little icky when working in a team.
jayd16 3y ago
It's probably about having to box value types.

eweise 3y ago

Java is still pretty ugly when you have to use the functions api https://docs.oracle.com/javase/8/docs/api/java/util/function/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/function.... I don't know why they can't make it like kotlin and scala where you just can just type the function definition instead of trying to find a class that represents what you want. This streams API for example, is unreadable. <R> R collect (Supplier<R> supplier, BiConsumer<R, ? super T> accumulator, BiConsumer<R, R> combiner)

DarkNova6 3y ago
I see the opposite. I think functional implementation of interfaces is lacking in Kotlin big time. The fact that you see a type like Comparable<T> and can implement it with an anonymous function is unique to Java. In other languages you would have Function<Int, T, T> which simply baffles the mind. Java has a powerful and performant model which also benefits from static and default methods (e.g. functional composition). Granted, the collect endpoint looks pretty wild but in 99% of cases you will simply use ".toList" or Collectors.toSet().
- eweise 3y ago
  I just meant that its much nicer to read and write (T) -> R vs Function<T,R> Maybe Kotlin lacks implementing interfaces functionally but in practice, I can't remember it being a pain point. Funtional programming in Java to me, still feels very clunky compared to scala and kotlin.