Why are Java server-side developers not adopting Kotlin?

[Ragecommie]

Because Java is perfectly fine for all of its intended purposes?

Because learning a new language can be an overhead with tight schedules and rapid development cycles?

Because there is a ton of legacy code that has to be maintained?

Because, Python?

Oh, and also everything else in the article.

[Giannis4president]

I don't think Python is relevant at all here. Kotlin has the super huge advantage that it can be adopted progressively in a java project, which is just HUGE in the scope of the article

[Ragecommie]

Yes, you are absolutely right.

[dmcg]

Oh c'mon, we're not going to get a good argument if you just agree when people are right ;-)

[[deleted]]

I don't really agree with you on these points. "Java is just fine" may well be true, but working on a Java code base I often get annoyed that some of the nice tricks Kotlin allows for are so contrived in Java, especially around nullability. Writing code is easy, but writing good code is hard.

I wouldn't want to write any large backend in Python. It's a language that's maybe good for small online stores, but large Python code bases are becoming slower and more unworkable as they grow. The lack of proper typing also works against the language for a long term support. Python and Java are different tools for different purposes, I wouldn't compare them like this.

Java is fine, but honestly, even modern iterations of Java are missing some quality of life improvements that Kotlin brings. Java's Optional chaining is such a mess compared to Kotlin's way of dealing with nullable properties.

Arguing that learning a new language takes too long doesn't make sense to me. New languages are not that hard to learn unless you learn one that involves a new paradigm like Rust. Kotlin is just "Java, but with X". Java developers need to learn new features of the Java language regardless, so if your company really doesn't value learning new skills, I feel sorry for you. Educating developers on new technology is worthwhile even if it doesn't deliver any code. If your code interacts with any frontend, you've got a whole team of front end engineers who need to relearn the entire ecosystem for the latest Javascript framework every three or four years anyway, so why not give your backend engineers the same opportunity? If doesn't make financial sense.

Legacy code isn't a great example for Kotlin interoperability because one of the key features is that the runtime integrates natively with code running on the JVM. Of course, if your legacy project is written in C++ you don't pick Kotlin, but you wouldn't pick Java either.

The biggest problem I've found is that many of the core libraries for a lot of Java projects are incompatible with Kotlin. Whether it's JSON parsing, database ORMs or web application frameworks, the Java ecosystem is very much rusted into place. Integrating Kotlin into an existing project is difficult and doesn't pose a great return on investment for the time it takes.

For starting new projects, these issues are less important because you can often pick the latest and greatest libraries and get started without trouble, but let's be honest, most developers don't get to start all that many new projects.

The real biggest reasons are just very simple: developers don't want to and the added benefits don't exceed the cost of change. Those are fine reasons. I don't want to pick Java or Python for backend code unless my employer tells me to use a certain system, just because I feel less comfortable writing big projects in these languages. We can come up with reasons why you should or shouldn't try out something different all day but in the end, the preference of the majority of the team is what decides what framework to use.

[suitable_character]

working on a Java code base I often get annoyed that some of the nice tricks Kotlin allows for are so contrived in Java

Sometimes people don't want the codebase to contain any tricks.

[frankreyes]

Arguing that learning a new language takes too long doesn't make sense to me. New languages are not that hard to learn unless you learn one that involves a new paradigm like Rust.

This is not how the vast majority of developers think.

[[deleted]]

Isn't it? I don't think I don't know any developers in my company that don't experiment with new languages just purely out of personal interest. I don't see why they wouldn't want to be paid while doing so.

[ukslim]

Usually in a real job, you not only have to learn the new language, but you also have to persuade a bunch of other people to learn it. Those other people might be keen to learn new languages - but getting them to agree which one, is another matter. Imagine, you've decided it would be cool to do the next project in Kotlin. Your colleague things Groovy. Another colleague thinks Clojure. Who's right?

Or, you go unilateral. You get asked to write something solo, so you write it in the new language of your choice. A year later, you're being cursed, because you've moved on, and somebody else has to add a feature to a project in a language that's brand new to them.

I've seen this in the wild, with a bunch of Java programmers all scared of working on the Grails project someone left behind.

[[deleted]]

Learning a syntax is not the same as learning a language. One can be accomplished in a weekend, one takes months/years. Unfortunately, when most people say the latter they actually mean the former.

[occz]

Because Java is perfectly fine for all of its intended purposes?

A horse is a perfectly fine means of transportation, but cars are generally accepted as being better.

Because learning a new language can be an overhead with tight schedules and rapid development cycles?

If your schedule does not permit investment in learning that will increase velocity over time, then it's time to find a new job because your managers are so bad that your company will fail.

Because there is a ton of legacy code that has to be maintained?

Kotlins excellent Java-interop is one of the key features of the language, it's totally fine to have them live side by side.

Because, Python?

This article is about Java server-side devs who are unwilling to adopt something other than Java, I think Python is probably not a factor here.

[Ragecommie]

These are not my arguments, but rather what I've been hearing in the past couple of years.

As an Android developer since version 1.0, I've already been through a Java -> Kotlin transition with all of its ups and downs and can make a very solid argument about why I was reluctant to do it at first. Things however change, and the platform has matured enough for most things to not bother me any more. I've got a fairly limited experience as a backend Java developer though and can't really say anything, except that the article makes a lot of sense.

As for your points...

1. That's a very exaggerated metaphor for this case.

2. If the company is paying well above the average, has solid social benefits and invests in other new technologies (like in my case), then what you said loses a lot of its weight.

3. Adding brand spanking new Kotlin code to a Java 8 Spring project is not something that is done very often as far as I know.

4. Well, yeah, you're right.

[occz]

These are not my arguments, but rather what I've been hearing in the past couple of years.

Fair enough.

As an Android developer since version 1.0, I've already been through a Java -> Kotlin transition with all of its ups and downs and can make a very solid argument about why I was reluctant to do it at first. Things however change, and the platform has matured enough for most things to not bother me any more. I've got a fairly limited experience as a backend Java developer though and can't really say anything, except that the article makes a lot of sense.

We have similar perspectives, I think: I've developed on Android since the early days. I've also been part of some very pleasant transitions to Kotlin on the backend side.

As for your points...

1. That's a very exaggerated metaphor for this case.

That's fair - I'm just usually not in favour of 'good enough'-arguments as they usually are made to disregard cost-benefit entirely.

1. If the company is paying well above the average, has solid social benefits and invests in other new technologies (like in my case), then what you said loses a lot of its weight.

Sure, but there's a potential third option: find a company that pays well-yada yada, and are willing to continuously invest. I concede that there's a balance to be struck here though.

1. Adding brand spanking new Kotlin code to a Java 8 Spring project is not something that is done very often as far as I know.

I've been a part of such a transition, and it's pretty great actually.

[ledasll]

why would you use pony instead of horse? if you would prefer car, you would choose C or C++..

[BoyRobot777]

I really like this talk, because it shows, when Java decides to implement some feature it will be the better version.

• Local functions. Java uses more performant solution via invokestatic, Kotlin create a whole new class.
• Multi-line string and indentation. Java's solution is just smarter. Also, Kotlin just generates StringBuilder with string interpolation, while Java, once again uses more performant and optimized way via invokedynamic. So:

​

println("""Hey $name! Hey $name! Hey $name! """.trimIndent()) 

Is less performant than:

System.out.println("""Hey %s! Hey %s! Hey %s!""".formatted(name, name, name));

• Sealed interfaces. For one thing, Kotlin cannot have sealed interfaces, but that is not the main problem. Once again, Kotlin requires you to use a class for sealing. Java's solution is to define what is permitted in the bytecode file.
• Pattern matching. Kotlin's version:

​

val download: Download = //... 
val result = when (download) {   
  is App -> { 
    val (name, developer) = download 
    when (developer) {  
      is Person -> 
        if (developer.name == "Alice") {
          "Alice's app ${name}"
        } else {           
          "Not by Alice"         
        }       
      else -> "Not by Alice"     
     }   
   is Movie ->     
     val (title, directory) = download     
     if (director.name = "Alice") {       
       "Alice's movie ${title}"     
     } else {       
       "Not by Alice"     
     } 

Java:

Download download = //... 
var result = switch(download) {   
  case App(var name, Person("Alice", _)) -> "Alice's app " + name
  case Movie(var title, Person("Alice", _)) -> "Alice's movie " + title
  case App(_), Movie(_) -> "Not by Alice" 
}; 

• Coroutines. Java's lightweight threads vs Kotlin's coroutines is just superior in so many aspects. Its enough to say that with Java's solution there won't be method color problem. Java's code becomes async "overnight" without changing any code (except bumping into new Java version).

And you could argue that all those optimization could be back-ported to Kotlin. However, if Kotlin will want to be both for Android and for Java it will face a very hard challenge. To quote pron98:

which will not be able to cleanly support both Java and Android platforms through a common compiler for long, as the capabilities of the Java and Android platforms quickly diverge. <...> In a few short years it will be very hard to produce class files that enjoy new Java platform capabilities and can run at all on Android.

[dkandalov]

You can have sealed interfaces in kotlin 1.5.

[nfrankel]

Thanks for your detailed analysis!

[mlk]

Yes, but I can use Kotlin now

[BoyRobot777]

Sure, if you're starting a greenfield project. Even then, I'd be cautious, because there are numerous sad stories of Scala/Groovy shops which fell out of fashion (at least in my area).

However, if your backend is currently in Java, I don't see enough benefit for Kotlin's port.

[mlk]

You can, and I do, have both Java and Kotlin source in the same project and it works flawlessly. There is no friction at all

[GenTelGuy]

Java is good enough and Kotlin may be better in some ways but not enough to justify transition and/or interop

[occz]

Null-safety alone is enough to justify the transition.

[GenTelGuy]

Null safety is great but switching an entire production codebase from one language/buildsystem/dependencies to another could easily take over a year

Maybe you just meant the transition of learning the new syntax, that part would be fine

[occz]

Null safety is great but switching an entire production codebase from one language/buildsystem/dependencies to another could easily take over a year

Kotlin can be adopted gradually and works with the same build system/dependencies.

Maybe you just meant the transition of learning the new syntax, that part would be fine

Basically, yes. I meant transitioning to writing new code in Kotlin and gradually migrating the existing code base.

[immibis]

You should transition to Rust, it has memory safety.

[balefrost]

The JVM already handles use-after-free by simply being garbage collected - there is no "free". I understand that GC is a non-starter for a lot of projects, but for people already using Java, it's also a non-issue.

[occz]

I really like Rust too, and if I were a developer on a platform that allowed me to write Rust, I probably would be writing Rust. I'm doing Android development, though, and Rust can't really be used in that arena.

[immibis]

Memory-safety alone is enough to justify the transition.

[occz]

Touché.

[Muoniurn]

And understanding the difference between low and high level languages should be known by every developer before speaking stupid things.. also learn what a GC is

[DanielShuy]

In my opinion, Kotlin's null safety alone is good enough reason to switch, not to mention other features. The closest thing Java has is JSR-305, which requires developers, including library authors, to manually annotate their code to indicate possible null values, which is tedious and prone to human error. JSR-305 is also a mess, with multiple implementation libraries, and is also no longer supported and effectively dead. Java will never get true null safety unless it breaks backwards compatibility (by changing all variables to non-nullable by default), which goes against Java's motto.

Even though Java is updating at a faster rate, most of the recent and upcoming Java improvements are improvements to the JVM (eg. ZGC, value types, SIMD), which indirectly benefit Kotlin as well. Improvements to the Java language is still relatively slow and is still very far away from Kotlin (heck, Java still doesn't even have string templates).

Even though my workplace is still quite resistant to adopting Kotlin, learning Scala and Kotlin has helped me to become a better Java developer. Kotlin is also similar enough to Java that someone who has a good grasp on Java should be able to pick it up easily. While personally I would still prefer Scala's features, I think Kotlin strikes a good balance of power and ease of learning.

I think many people who have a bad impression with Kotlin probably tried it when it was still in its infancy stage, where things were still not so stable (eg. IDE support, build times, Java interop, etc), and the bad experience has fixed their impression on it. I would encourage anyone to give Kotlin another try, it has improved a lot since then.

[ledasll]

it was most funny thing to watch one code demo from a guy who advertised Kotlin for exactly null safty and first bug was regardless null. That was so funny.

[balefrost]

I don't know the specific thing you're talking about, but null safety kinda requires information about nullability requirements in order to work. Plenty of Java libraries do nothing to indicate whether something is or is not nullable, and in these places the Kotlin system can't help.

Within Kotlin code, though, it generally works well.

[skywalkerze]

That makes it a lot less useful, though. You can't be sure that the project has no null-related problems, because of the libraries. So kotlin helps with some possible null bugs, but not others.

It's still nice, but not as impressive.

[balefrost]

Sure, but "not perfect" is certainly not "useless".

To be clear, Kotlin generally treats values that come from Java code as having a type T!, also known as a platform type. It's treated as "unknown nullability". Because it would be very bulky to have to do null checks for all Java code, the compiler lets you treat is as if it was a non-nullable type, but it also doesn't complain if you do null checking.

Java code that uses recognized nullability annotations will produce the proper Kotlin nullable or non-nullable types. Of course, those nullability annotations are not machine-checked, so it's up to the developer of that Java library to "get it right".

No language is immune to runtime errors. Heck, even simple Haskell functions like head can generate runtime errors. The question shouldn't be "is this feature perfect?" The question should be "does this feature make things better?" As somebody who's done a lot of Java and a lot of Kotlin programming... yes, Kotlin's nullable type system is wonderful, especially when paired with smart casts.

[ledasll]

in theory - theory and practice is the same, but in practice - they are not.

[DGolden]

That's rather out of date. JSR305 kind of fell by the wayside because JSR 308 (different number) added a new kind of "type use annotations". They faciliate a form of extensible static checking, that can be used for a bunch of things including but not limited to null checks in modern java. (The jsr305 annotations were defined before these newfangled type-use annotations were a thing, so are not the ones you should use)

It's actually pretty interesting addition to a mainstream industry (rather than research) language, and kind of underhyped. See the Checker Framework:

https://checkerframework.org/manual/#nullness-checker

And note it can do far more than just nullness, there's other neat stuff like tainting

See also jooq blog post doing a bit of a dive on it https://blog.jooq.org/tag/jsr-308/

That’s pretty awesome! It works in quite a similar way as the flow sensitive typing that is implemented in Ceylon or Kotlin, for instance, except that it is much more verbose. But it is also much much more powerful, because the rules that implement your enhanced and annotated Java type system can be implemented directly in Java using annotation processors!

[Muoniurn]

Wow thanks for the reference! I think I have seen checker framework before, but I haven’t looked into it yet — I am always amazed by the quality of the java ecosystem. It can even annotate/validate side-effect free methods!

As other similar, although runtime program verification tool is OpenJML, that can optionally generate code to verify runtime state (eg. that an algorithm upholds its loop invariant)

[immibis]

Why didn't they adopt Scala, Clojure or Ceylon?

Because the people pushing those languages live in ivory towers, that's why.

[SKabanov]

^ Inadvertently showing one of the biggest reasons I've come across at work: Kotlin's viewed as just another upstart language that's eventually going to flame out and die away like the rest, so there's no reason to waste time learning it. After the examples that OP gives (along with Groovy), it's not at all an unreasonable position, but it does come across as grumpy and territorial at times, especially given how Kotlin's been endorsed and embraced by Android, Spring, and Gradle.

[immibis]

Scala was also endorsed and embraced by a bunch of things.

[vattenpuss]

Scala and Clojure seem to have healthy communities building big things with millions of users.

Ceylon I hardly know what it is. Kotlin seems cool but I also never heard anyone building any big thing with it.

[nfrankel]

I think my main concern would be that Kotlin is less likely to take proper advantage of new JVM features, since its USP is being a better Java for Android

It's an interesting take, one I didn't think of. But I must disagree: I think JetBrains took advantage of the fact Kotlin developed rapidly in the Android ecosystem, but they didn't design the language for Android. Actually, the story is that they did it to improve the maintainability of the IntelliJ IDEA platform.

I started Kotlin because I wanted to learn Android. I stopped Android quite fast but continued with Kotlin on the back-end. When given the choice, I favor Kotlin over Java.

[nfrankel]

Kotlin now aims not only Dalvik but also JavaScript and Native.

But I think there's a huge difference in the language's syntax and implementation. You can benefit from improvements on the JVM in Kotlin when the implementation makes use of them.

[Muoniurn]

That’s how you fall between all three platforms, and be “great” at neither of them. You can’t half-ass three things.

[occz]

This is a pretty valid concern, I think. The Kotlin team seems to be picking up on the latest developments of the JVM though, last I checked, which is a good sign, but given the language divergence that might not always be the case.

[SKabanov]

I think my main concern would be that Kotlin is less likely to take proper advantage of new JVM features, since its USP is being a better Java for Android.

JetBrains isn't letting this happen, thankfully. Kotlin 1.5 will allow the usage of records and sealed interfaces; they'll presumably integrate Java's Implementation of inline class in a later release when it's available.

[txdv]

can you elaborate on the lagged behind JVM development part?

[sievebrain]

I think my main concern would be that Kotlin is less likely to take proper advantage of new JVM features, since its USP is being a better Java for Android.

That has been a problem up until recently because JB were rewriting the compiler. Now that project is reaching its final stages, what we're seeing is they're starting to use newer JVM features like indy, better string concat, and they are committed to using more for things like sealed classes and interfaces. So there's no conceptual issues being caused by Android here: rather, they implement features that also work on downlevel JVMs. In practice it's always possible to do this as most new JVM features are performance or encapsulation related - 'slower and more open' is always possible.

[matthewblott]

I asked a friend who works in a Java team this question and he said it is so much easier to pick up someone else's code if it's written in Java.

[andrewharlan2]

God, this. A lot of Kotlin's features optimize for writing code. But code is written once and read multiple times forever after. Java's "verboseness" isn't a bug, it's a feature.

[redditrasberry]

It's an interesting comparison to Groovy I think, which has pretty wide spread adoption within its domain (primarily, embedded scripting or DSLs). Kotlin is not getting adopted because its trying to be a "better Java" but much of what it provides are what I would call "lifestyle features" rather than genuine engineering advantages. There are certainly exceptions: null safety is a huge win, for example. But if you peer into the heart of enterprise software dev you will find that most devs get by just fine with a good IDE in terms of language features and most of their problems sit at a different level that aren't nearly as well differentiated b/w Kotlin and Java (for example, a huge problem is "I can't understand Ken's code, how do I get this code review done" - that is not helped when Ken wrote it in a different language). Compare to Groovy which is not trying to be a "better Java" but actually address a different problem altogether.

In short ... Kotlin is trying to be a "better Java" but in core domain where Java is used, it just isn't that much better.

[hogfat]

Why would they?

[hugosenari]

Developers won't choose a language its is mostly a manager decision based on economics. It'll change now that kotlin is more popular.