Dear developers! In Kotlin team we try to understa...

# server

[Anton Yalyshev [JB]]

Dear developers! In Kotlin team we try to understand better the way how our language becomes accepted in projects and teams. We assume that usually it starts from one or several enthusiasts, and then they need to convince the rest of the team or the managers to introduce Kotlin into the project (to include into the allowed set of technologies).
If you are now in such kind of process, of had it recently - we would really like to know how exactly this happens(ed): what objections, doubts, conditions the team/manager expresses. What reasoning works and what doesn’t. We would like to make a kind of guidance, or F.A.Q. for that (provide information that people who make the decision might want to know about Kotlin), but before we want to learnt how it goes. If you’re up to share with us your experience, please respond with 👋 - I’ll reach you a bit later in DM.

[Leo N]

Adoption at my company has been good, but some teams gave pushback with the following arguments:
• Isn't it mostly for Android?
• Doesn't Java have good concurrency now? Why don't we just use that?
• What if Ktor becomes like Akka and starts charging for licenses?

[Leo N]

Most teams did enjoy:
• The concise and expressive syntax
• Null safety and Immutability features
• Convenient standard lib

[Johann Pardanaud]

One argument I heard is the lack of LSP for Kotlin, which makes the developers completely dependant on IntelliJ. What if JetBrains shuts down IJ community? I know this won't happening, but it's a valid concern.

[Joshua Angolano]

I get the isn't kotlin just for android a lot. I also hear we have Java, why do we need another JVM language.

It has been easy to convince teams to use Kotlin that are using typescript as they both of concise syntax and null safety.

I think Spring having first class support helps a ton!

[Peter Ertl]

I would appreciate some higher level language features comparable to scala, since kotlin does not suffer from binary compatibility issues like scala in major versions and integrates smoother with java itself

[Tim Schraepen]

I have a 1hour presentation about how it’s important for us Kotlin enthusiasts to learn how to do this.
• What to pay attention to.
• How it’s a skill you can learn. (Grow your own luck)
• What not to do.
• And how I’ve applied it in a real life experience.
Still, I have learned even more over the course of a year after having made that presentation.

[Tim Schraepen]

From management/architects the argument I’ve heard most is “we won’t find kotlin developers”, mostly in combination with “we already have java developers now, they might not all want to learn Kotlin”. (It’s the longevity/support argument)
From developers the argument I’ve heard the most is “Java will eventually have all of the kotlin features anyway, why learn Kotlin now, just to have better syntactical sugar”. (Disregarding that they’re also writing in TypeScript for the frontend part of their applications) And although it doesn’t make sense, these are the statements and rhetoric we have to learn how to deal with.

I don’t believe you can solve this with a F.A.Q.

[Tim Schraepen]

The approach that doesn’t work is to “try harder”, “convince harder”, “provide better arguments”.
Because it causes even more polarization.

[Çağatay Kalan]

My business partner has similar concerns about switching to Kotlin, including these:
• Long-term support and maintenance: We used Grails in several successful products, but over time it fell behind the latest tech stack, and some bugs remained unresolved for far too long. That experience made us cautious about adopting newer platforms
• Stability of the Lombok plugin: Most of our Java code relies on Lombok, but the Kotlin plugin for it is still experimental. We can't confidently assume that we won’t need to make changes with future Kotlin upgrades.
• Kotlin standard library dependency: It's another dependency to manage, and potentially a source of conflicts, especially when integrating with existing Java libraries.
• Limitations in public API design for internal and external libraries:
◦ No package-private scope
◦ No compiler support for checked exceptions
◦ KDoc limitations and Dokka Javadoc being buggy and still in alpha
In the end, I convinced him to use Kotlin at least in the applications where we have control of the dependency stack and only in higher-level presentation and service layers, i.e. controllers, services, jobs, CLI commands as any negative impact of the above listed concerns is much more manageable at that level. We still write the core business logic in Java, and we use pure Java for libraries we plan to publish for Java developers.

I first convinced people to write only the test code in Kotlin. That made the team feel the productivity and fun. Once they got used to Kotlin, we started using it in production code.