7 ms·

Modern Java still isn’t as nice as Kotlin. It’s just not as terrible as the Java version for Android.

by dep_b 6y ago

The_Colonel 6y ago
Java can't be as nice as Kotlin without breaking a ton of BC. So not gonna happen.
- 2OEH8eoCRo0 6y ago
  Honest question- why would anyone choose Java when starting a new software project today for any reason?
  - zoomablemind 6y ago
    Very obviously asking, what's your 'recommended' choices and why?
    - 2OEH8eoCRo0 6y ago
      I was asking in general not just about Java in relation to Android. Java has always felt like a clunky and closed language under the dictatorship of Oracle. Why not C++ or Rust? Does Java have any benefits that these two lack? I'm probably ignorant here. I haven't coded in Java for 5+ years.
      - pjmlp 6y ago
        Indeed, had it not been for Oracle's work and Java would have been stuck at version 6, Maxime would never been made into GraalVM, all AOT compilers for Java would still be only available via commercial JDK, (almost) zero pause GC with support for TB heaps, JNI replacement, support for SIMD/AVX512, incoming support for value types and rewrite of C++ stuff into Java would never have happened. People like to talk and bash Oracle, but no one else, including Google bothered with Sun assets, and the community on their own would never made the improvements that Oracle has made in the last 15 years, if the way of Python and Ruby are any indication of how runtime improvements get made.
  - tomc1985 6y ago
    I've started some personal projects in Java because I got tired of mentally translating example code or library documentation to Kotlin
    - The_rationalist 6y ago
      Intellij has an automatic translator that works really well though
      - tomc1985 6y ago
        It does, but I could only get it to trigger in certain circumstances (I think it was upon pasting in Java code into a Kotlin file) What I really wanted with regards to that feature was a textbuffer that can accept arbitrary fragments and translate those to Kotlin without committing anything to disk. But it has been a few years, I should check back on that
  - p2detar 6y ago
    Multiplattform, tons of libs and tools, statically compiled, supported by major IDEs, mature dependency management (maven, gradle), backed up a major player (Oracle). I’m sure there’s more.
    - distances 6y ago
      This was about Kotlin and Java, so of course Kotlin has all of that as it's using the Java ecosystem.
      - p2detar 6y ago
        The question was about Java. I, for example, use both Java and Kotlin in my project.
  - woile 6y ago
    Because you have a team of Java developers, or most of the tooling you are gonna use is around Java (eg: data streaming). My team had to write some flink, luckily in python you can do some now. Modern versions are not as bad (to me) you can use val for type inferring. If irc they are implementing stuff similar to scala. It's used quite a lot in enterprise as well. Note: by no means I'm a Java dev, I learnt to hate it a little less.
  - vips7L 6y ago
    In my eyes, the question is always why Kotlin? I don't think it offers much over modern Java. Maybe data classes? That's not a game changer to me. Coroutines? Loom will be better. Nullable references? This might be worth it, but in my experience Optional<T> is enough.
    - nitrogen 6y ago
      IMO it's mostly syntactic convenience and elimination of boilerplate. The Kotlin collections APIs are more convenient than the streams APIs. Data classes are convenient. Nullability is significantly more convenient than Optional. And you get all that even if you have to target old JVM versions for some reason.
    - rhencke 6y ago
      Groovy-like DSLs with compile-time checking and strong typing (and now @DslMarker is a nice bonus) are very nice. Check out inline functions and reified generics, too. There's some compelling stuff there.
    - freeone3000 6y ago
      Optional<T> is itself a reference and can itself be null. That effectively torpedos the entire concept out of the gate. Nullity being part of the data type is a huge difference, and exposes so many "I didn't know that could be null" spaces.
      - vips7L 6y ago
        I just see that as a non-argument. No one in their right mind returns null instead of Optional.empty() and I've never seen it done in the wild. Regardless in kotlin you can simply do: val s: String? = null return s as String or val s: String? = null !!s.trim() and lose all safety around nullability. Both hinge on a rogue developer not following best practices.
        The_Colonel 6y ago
        I've seen both Optional<?> return null (inexperienced dev) and somebody arguing we should defensively check for null Optionals as well (experienced dev). What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.

Modern Java still isn’t as nice as Kotlin. It’s just not as terrible as the Java version for Android.

by dep_b 6y ago

Modern Java still isn’t as nice as Kotlin. It’s just not as terrible as the Java version for Android.

The_Colonel 6y ago

Java can't be as nice as Kotlin without breaking a ton of BC. So not gonna happen.

2OEH8eoCRo0 6y ago
Honest question- why would anyone choose Java when starting a new software project today for any reason?
- zoomablemind 6y ago
  Very obviously asking, what's your 'recommended' choices and why?
  - 2OEH8eoCRo0 6y ago
    I was asking in general not just about Java in relation to Android. Java has always felt like a clunky and closed language under the dictatorship of Oracle. Why not C++ or Rust? Does Java have any benefits that these two lack? I'm probably ignorant here. I haven't coded in Java for 5+ years.
    - pjmlp 6y ago
      Indeed, had it not been for Oracle's work and Java would have been stuck at version 6, Maxime would never been made into GraalVM, all AOT compilers for Java would still be only available via commercial JDK, (almost) zero pause GC with support for TB heaps, JNI replacement, support for SIMD/AVX512, incoming support for value types and rewrite of C++ stuff into Java would never have happened. People like to talk and bash Oracle, but no one else, including Google bothered with Sun assets, and the community on their own would never made the improvements that Oracle has made in the last 15 years, if the way of Python and Ruby are any indication of how runtime improvements get made.
- tomc1985 6y ago
  I've started some personal projects in Java because I got tired of mentally translating example code or library documentation to Kotlin
  - The_rationalist 6y ago
    Intellij has an automatic translator that works really well though
    - tomc1985 6y ago
      It does, but I could only get it to trigger in certain circumstances (I think it was upon pasting in Java code into a Kotlin file) What I really wanted with regards to that feature was a textbuffer that can accept arbitrary fragments and translate those to Kotlin without committing anything to disk. But it has been a few years, I should check back on that
- p2detar 6y ago
  Multiplattform, tons of libs and tools, statically compiled, supported by major IDEs, mature dependency management (maven, gradle), backed up a major player (Oracle). I’m sure there’s more.
  - distances 6y ago
    This was about Kotlin and Java, so of course Kotlin has all of that as it's using the Java ecosystem.
    - p2detar 6y ago
      The question was about Java. I, for example, use both Java and Kotlin in my project.
- woile 6y ago
  Because you have a team of Java developers, or most of the tooling you are gonna use is around Java (eg: data streaming). My team had to write some flink, luckily in python you can do some now. Modern versions are not as bad (to me) you can use val for type inferring. If irc they are implementing stuff similar to scala. It's used quite a lot in enterprise as well. Note: by no means I'm a Java dev, I learnt to hate it a little less.
- vips7L 6y ago
  In my eyes, the question is always why Kotlin? I don't think it offers much over modern Java. Maybe data classes? That's not a game changer to me. Coroutines? Loom will be better. Nullable references? This might be worth it, but in my experience Optional<T> is enough.
  - nitrogen 6y ago
    IMO it's mostly syntactic convenience and elimination of boilerplate. The Kotlin collections APIs are more convenient than the streams APIs. Data classes are convenient. Nullability is significantly more convenient than Optional. And you get all that even if you have to target old JVM versions for some reason.
  - rhencke 6y ago
    Groovy-like DSLs with compile-time checking and strong typing (and now @DslMarker is a nice bonus) are very nice. Check out inline functions and reified generics, too. There's some compelling stuff there.
  - freeone3000 6y ago
    Optional<T> is itself a reference and can itself be null. That effectively torpedos the entire concept out of the gate. Nullity being part of the data type is a huge difference, and exposes so many "I didn't know that could be null" spaces.
    - vips7L 6y ago
      I just see that as a non-argument. No one in their right mind returns null instead of Optional.empty() and I've never seen it done in the wild. Regardless in kotlin you can simply do: val s: String? = null return s as String or val s: String? = null !!s.trim() and lose all safety around nullability. Both hinge on a rogue developer not following best practices.
      - The_Colonel 6y ago
        I've seen both Optional<?> return null (inexperienced dev) and somebody arguing we should defensively check for null Optionals as well (experienced dev). What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.