7 ms·

I work in a fintech company, most of our backend is in Kotlin with "legacy" functionality in Java. Can't think of a single developer that would choose Java ove

I work in a fintech company, most of our backend is in Kotlin with "legacy" functionality in Java. Can't think of a single developer that would choose Java over Kotlin.

chrisseaton 6y ago
I'd choose Java over Kotlin. The benefits of Kotlin seem minor - mostly syntactic sugar - and the tooling is more limited than Java. They seem to solve problems with kludges (like their coroutines are really just state machines in JVM bytecode, which creates issues like irreducible control-flow) rather than properly engineering solutions like Java try to do.
- sorokod 6y ago
  Just sharing my experience, to each his own.
- balfirevic 6y ago
  How did Java (as opposed to JVM) try to properly engineer solution to the problem coroutines were created to solve?
  - jsiepkes 6y ago
    Project Loom: https://openjdk.java.net/projects/loom/ https://openjdk.java.net/projects/loom/ The view being that async-await leads to a "What color is your function" problem ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).
    - balfirevic 6y ago
      "As opposed to JVM" You don't have to convince me that green threads are far superior to async-await - I already believe that. But that's not something Kotlin (nor Java, on the language level) could have solved.
      - vips7L 6y ago
        You're correct but you're forgetting that the jvm IS java. When it isn't trivial to solve at the language level they have the power to change the runtime.
        jsiepkes 6y ago
        And on top of that Kotlin is now basically stuck with async-await forever. Removing async-await from the language and designing a more superior model the JVM now allows for with Loom is probably not going to happen. Adding a new model based on the new possibilities Loom provides will probably cause too much fragmentation (unless they come up with some really clever interop) so thats also unlikely. Kotlin could be stuck here with a inferior co-routine model; Handicap of a headstart. Tough of course time will have to tell if the model Loom introduces in Java is going to be as great as it sounds.
  - chrisseaton 6y ago
    > How did Java (as opposed to JVM) Well that’s the point - they solved it in the JVM not as a kludge of bytecode.
    - balfirevic 6y ago
      Well, once that happened Kotlin also gets the solution. It's rude and unfair to call out a language as "solving the problems with kludges" when they literally could not have done anything better.
      - chrisseaton 6y ago
        Anyone can propose changes to the JVM. The Java people did. The Kotlin people didn't. And the Kotlin approach generates bad (irreducible) bytecode.
      - jdmichal 6y ago
        Yet the JVM had `invokedynamic` before it had any use in Java, specifically to support more dynamic languages.
- peheje 6y ago
  But... When Java gets "properly engineered solution" for async code... Kotlin got it as well!
  - chrisseaton 6y ago
    So why bother using Kotlin? Seems like it fixes trivial things (makes simple classes a bit more terse) but retains the more fundamental problems and hangs on for Java to actually fix those.
    - dbsmith83 6y ago
      It's way more than terse classes. The syntax everywhere is cleaner. Higher order functions look so much nicer. Using val/var is superior to having to remember to write 'final' all the time. Kotlin also handles nullability way better. Ah, also, default arguments for constructors/methods. These features prevent a lot of developer mistakes, and thus better code is often achieved. Also, Kotlin usually forges ahead on features, and the Java is playing catch up. Take data classes for instance. If anything it seems like Kotlin gave Java a good kick in the pants to get it to start developing faster and adding modern language features.
      - pjmlp 6y ago
        Java and JVM are developed together, Kotlin just adds syntax sugar on top. If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?
        dbsmith83 6y ago
        Because there are benefits to the JVM and interoperability with Java
        pjmlp 6y ago
        Apparently not, given the cargo cult hate against Java on Kotlin community, glad to "leave Java behind".
- dbsmith83 6y ago
  How is the tooling more limited? I have never had a problem using any java library/framework with Kotlin.
pjmlp 6y ago
Here is one, outside Android, Kotlin is other guest language that will fail to take Java's place on the Java Virtual Machine.
- jorgemf 6y ago
  Why do you say so? I do think kotlin isnt only aiming to the Java Virtual Machine, it is mucho more.
  - pjmlp 6y ago
    Life experience of seeing guest languages come and go, during the last 30 years, and never succeeding in the goal to replace platform languages. On the contrary, platform languages slowly acquire the relevant features of the shiny languages, which eventually either fade away or find a niche for survival. Kotlin will be relevant as long as Android exists, that is all.
    - tadfisher 6y ago
      Scala, Clojure, and Groovy are all mature languages that haven't gone anywhere. No one has a goal of replacing Java, and they all benefit from improvements to the JVM.
      - pjmlp 6y ago
        Mere blips on the Java eco-system, why do you think Typesafe has pivoted into Lightbend and now also does Java projects? Gradle and Google choosing it for Android are the only things that keeps Groovy still relevant. As for Clojure, it is its own thing, plugging into the host platforms.
      - blandflakes 6y ago
        Of the JVM languages, AFAIK only Kotlin is making a serious push to get off the JVM using something like LLVM. Interesting idea, though I wonder how long they can preserve compatibility between JVM and native targets. Scala native doesn't feel like it has the same impact, perhaps in part due to a lack of momentum (as I perceive it).

I work in a fintech company, most of our backend is in Kotlin with "legacy" functionality in Java. Can't think of a single developer that would choose Java over Kotlin.

chrisseaton 6y ago

I'd choose Java over Kotlin. The benefits of Kotlin seem minor - mostly syntactic sugar - and the tooling is more limited than Java. They seem to solve problems with kludges (like their coroutines are really just state machines in JVM bytecode, which creates issues like irreducible control-flow) rather than properly engineering solutions like Java try to do.

sorokod 6y ago
Just sharing my experience, to each his own.
balfirevic 6y ago
How did Java (as opposed to JVM) try to properly engineer solution to the problem coroutines were created to solve?
- jsiepkes 6y ago
  Project Loom: https://openjdk.java.net/projects/loom/ https://openjdk.java.net/projects/loom/ The view being that async-await leads to a "What color is your function" problem ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).
  - balfirevic 6y ago
    "As opposed to JVM" You don't have to convince me that green threads are far superior to async-await - I already believe that. But that's not something Kotlin (nor Java, on the language level) could have solved.
    - vips7L 6y ago
      You're correct but you're forgetting that the jvm IS java. When it isn't trivial to solve at the language level they have the power to change the runtime.
      - jsiepkes 6y ago
        And on top of that Kotlin is now basically stuck with async-await forever. Removing async-await from the language and designing a more superior model the JVM now allows for with Loom is probably not going to happen. Adding a new model based on the new possibilities Loom provides will probably cause too much fragmentation (unless they come up with some really clever interop) so thats also unlikely. Kotlin could be stuck here with a inferior co-routine model; Handicap of a headstart. Tough of course time will have to tell if the model Loom introduces in Java is going to be as great as it sounds.
- chrisseaton 6y ago
  > How did Java (as opposed to JVM) Well that’s the point - they solved it in the JVM not as a kludge of bytecode.
  - balfirevic 6y ago
    Well, once that happened Kotlin also gets the solution. It's rude and unfair to call out a language as "solving the problems with kludges" when they literally could not have done anything better.
    - chrisseaton 6y ago
      Anyone can propose changes to the JVM. The Java people did. The Kotlin people didn't. And the Kotlin approach generates bad (irreducible) bytecode.
    - jdmichal 6y ago
      Yet the JVM had `invokedynamic` before it had any use in Java, specifically to support more dynamic languages.
peheje 6y ago
But... When Java gets "properly engineered solution" for async code... Kotlin got it as well!
- chrisseaton 6y ago
  So why bother using Kotlin? Seems like it fixes trivial things (makes simple classes a bit more terse) but retains the more fundamental problems and hangs on for Java to actually fix those.
  - dbsmith83 6y ago
    It's way more than terse classes. The syntax everywhere is cleaner. Higher order functions look so much nicer. Using val/var is superior to having to remember to write 'final' all the time. Kotlin also handles nullability way better. Ah, also, default arguments for constructors/methods. These features prevent a lot of developer mistakes, and thus better code is often achieved. Also, Kotlin usually forges ahead on features, and the Java is playing catch up. Take data classes for instance. If anything it seems like Kotlin gave Java a good kick in the pants to get it to start developing faster and adding modern language features.
    - pjmlp 6y ago
      Java and JVM are developed together, Kotlin just adds syntax sugar on top. If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?
      - dbsmith83 6y ago
        Because there are benefits to the JVM and interoperability with Java
        pjmlp 6y ago
        Apparently not, given the cargo cult hate against Java on Kotlin community, glad to "leave Java behind".
dbsmith83 6y ago
How is the tooling more limited? I have never had a problem using any java library/framework with Kotlin.

pjmlp 6y ago

Here is one, outside Android, Kotlin is other guest language that will fail to take Java's place on the Java Virtual Machine.

jorgemf 6y ago
Why do you say so? I do think kotlin isnt only aiming to the Java Virtual Machine, it is mucho more.
- pjmlp 6y ago
  Life experience of seeing guest languages come and go, during the last 30 years, and never succeeding in the goal to replace platform languages. On the contrary, platform languages slowly acquire the relevant features of the shiny languages, which eventually either fade away or find a niche for survival. Kotlin will be relevant as long as Android exists, that is all.
  - tadfisher 6y ago
    Scala, Clojure, and Groovy are all mature languages that haven't gone anywhere. No one has a goal of replacing Java, and they all benefit from improvements to the JVM.
    - pjmlp 6y ago
      Mere blips on the Java eco-system, why do you think Typesafe has pivoted into Lightbend and now also does Java projects? Gradle and Google choosing it for Android are the only things that keeps Groovy still relevant. As for Clojure, it is its own thing, plugging into the host platforms.
    - blandflakes 6y ago
      Of the JVM languages, AFAIK only Kotlin is making a serious push to get off the JVM using something like LLVM. Interesting idea, though I wonder how long they can preserve compatibility between JVM and native targets. Scala native doesn't feel like it has the same impact, perhaps in part due to a lack of momentum (as I perceive it).