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.

But... When Java gets "properly engineered solution" for async code... Kotlin got it as well!

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.

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.

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?

Because there are benefits to the JVM and interoperability with Java

Apparently not, given the cargo cult hate against Java on Kotlin community, glad to "leave Java behind".

If Kotlin's only improvement over Java were its scope functions, that alone would be an overwhelmingly good reason to migrate. Scope functions are awesome, cannot stress that enough.

Kotlin syntax makes writing functional code beautiful and simple... map and fold and filter are so much easier to write than in any other language that also have the same functions, such as JS. Again, that alone would be enough to migrate.

But there are still so many more simple, but incredibly useful functions like SubstringAfterLast which takes a nasty, ugly Split function into a beautiful, precise line of code. Just one example of many.

import static

Kotlin fixes just trivial things - like nullability for example. Java still doesn't have a good solution, only about 5 bad ones and nothing is in sight. It even looks like Java designers simply don't consider it a problem anymore ...

Instead, they focus on things like value types. Which are definitely cool, but they don't actually solve any of my problems. Typical business apps written in Java don't suffer from performance issues, they suffer from (accidental) complexity explosion and subsequent buginess (of which NPEs is a symptom).

When teams go so far as to consider alternatives to the JVM, memory footprint and poorly tuned GC are typical reasons.

Not at all, because Kotlin wants to take it all, so they need to make the choice if they want to expose JVM features, or keep the language portable across all platforms that JetBrains wants to target with Kotlin.

A good example is Kotlin/Native, by choosing a memory model incompatible with JVM code they failed, and were forced to go back into the drawing board for Kotlin/Native with a proper tracing GC.

If I were to use Kotlin server-side on JVM and didn't care about portability to other Kotlin platforms, could I not just use JVM green threads?

Depends on how Kotlin decides to expose them at the language level.

For example, you need special syntax to use SAM types and Kotlin cannot use all use cases from interfaces with default methods.

That is the thing with the Java Virtual Machine, the bytecodes and runtime are designed for Java, all guest languages have to pretend to be Java.

Just disassemble the amount of boilerplate generated by the Kolin compiler.

This is not always the case. One example is checked exceptions which are purely Java thing and do not exist in JVM (outside of metadata). That always amused me, it's like a switch to remove checked exceptions from language, you can turn it any time without backward compatibility issues.

Another example is inner classes. Inner class can access private fields of outer class in Java. But in JVM there's no inner class concept, so compiler generates synthetic accessors for outer class private fields and inner class uses those methods to access private fields. That was fixed recently, though, but it was the case for many decades.

Also I remember some funny bytecode with try-finally, I think it's implemented with gotos.

Of course Kotlin generates a lot more boilerplate, that's for sure.

How did Java (as opposed to JVM) try to properly engineer solution to the problem coroutines were created to solve?

Project 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-... ).

"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.

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.

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.

> How did Java (as opposed to JVM)

Well that’s the point - they solved it in the JVM not as a kludge of bytecode.

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.

Anyone can propose changes to the JVM. The Java people did. The Kotlin people didn't. And the Kotlin approach generates bad (irreducible) bytecode.

Yet the JVM had `invokedynamic` before it had any use in Java, specifically to support more dynamic languages.

How is the tooling more limited? I have never had a problem using any java library/framework with Kotlin.

Just sharing my experience, to each his own.

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

Why do you say so?

I do think kotlin isnt only aiming to the Java Virtual Machine, it is mucho more.

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.

Entirely replacing estabilished languages doesn't really ever happen, it's just the nature of the game.

Server software for unixy systems used to be near universally written in C and it's still "the" platform language. And it can be certainly be said that alternative languages have come and gone.

But: C has become a niche.

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.

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.

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).

Clojure exists outside the JVM as well (ClojureScript, Babashka, ClojureCLR)

It does, but not in the same platform-antagonistic way. Clojure instead embraces many different platforms and runs on them through various dialects; Kotlin wants to become a platform.

Scala preceded it with both Scala Native and ScalaJS.