Hi, this might be a bit unconventional question, b...

# getting-started

[Gabor Torok]

Hi, this might be a bit unconventional question, but right now i am working on a presentation that should convince leadership that it’s okay for us to use Kotlin. so far the presentation is mostly about addressing/mitigating the risks/concerns involved, but of course I also have to convince people that it is worth taking on those risks.

this creates an interesting problem. for me Kotlin does have a huge list of benefits, but due to the time constraints and attention span constraints i can’t really just go ahead and nerd out about them. also the audience is a bit different, have to aim at leadership instead of the developer.

so the question is: if you have 3 slides to talk about why how using Kotlin would benefit your manager, which features/benefits would you talk about and why?

[dp]

I’m really new to Kotlin so I can’t really help with the content but, in general, tech decisions are contextual. Some questions for you that might help people answer your questions:

1. What industry are you in?
2. What are the pain points of your current tech stack?
3. How large is your company?
4. How many developers would be affected by the switch? Are they already onboard with switching to Kotlin?
5. Do the current developers know Kotlin?
6. Would it be hard to hire Kotlin devs in your industry?
7. Are you wanting to migrate existing projects or just start greenfield projects with Kotlin?

[Adam Powell]

What is the status quo/what would you use if not Kotlin?

[Gabor Torok]

okay, that is fair, maybe i should add more context 🙂


• currently we are on a java stack, and have a significant sized code-base.
• i am trying to propose a pilot stuff, allowing Kotlin in some part of the codebase that is maintained by our team, who is very much onboard. no migration, no rewrites, we are only proposing it for new code and where it makes sense for refactoring.
• kotlin would be used on server-side, living next to java code.
• due to the monorepo approach, this would affect everyones code in some ways.
• mostly the eclipse users, those who develop using intellij wouldn’t even notice… 😛
• i have significant kotlin experience, net 3 years i have been using it as my main development language. through my career this is the third time i am part of a team attempting this, and the other two were quite successful, although at other times it did not take this much convincing.. :)
i have already done a quite extensive risk assessment, looking at build times, performance, how to mitigate learning issues, eclipse issues, compatibility issues, etc. now i am focusing on making the presentation actually presentable in the timeframe, that’s why i am faced with that kind of arbitrary three-slide limitation.

addressing risks only takes makes half of the sell, i also need to mention the benefits, but which ones, in such a limited time and slides, and to an audience that is more manager than developer.

so while i got some ideas, and favourite features, i am very much interested in what other devs/managers think, what are the killer features for them?

[Joffrey]

I think one of the major killer features to highlight when migrating from a Java context would be the null safety. Crashes are scary for everyone and catching issues at compile time is often a lifesaver.

You can start from null safety as a very concrete example and expand by pointing out that other parts of the type system have been improved over java (for instance generics), which allows to catch more errors at compile time.

[Gabor Torok]

yeah, i like the angle of emphasizing how the compiler protects you from more problems, thanks!

[Victor Cardona]

I did this at my former employer. I would focus on the following:
1. null safety as it helps reduce if not eliminate the most common exception thrown by Java code.
2. Opinionated language as it provides guardrails for developers that encourage them to follow good coding practices. Things like immutability, favoring composition over inheritance, etc…
3. Interoperability with Java allowing you to mix in a single code base, and to take advantage of new JVM features as they become available.
4. Low ramp up time for developers. Experienced Java developers can be productive in Kotlin in 1-2 weeks time.

[Adam Powell]

Structured concurrency is also a huge win for correctness and avoiding bugs but not one that will be realized overnight

[Gabor Torok]

@Victor Cardona these are great stuff, thank you!

[Joffrey]

About structured concurrency and coroutines, you might get questions around Loom. It should be noted that while Loom might solve a similar problem as coroutines (at a low level), it doesn't bring the structured concurrency toolset that kotlinx.coroutines brings, so they can actually work together (there is a good chance <http://Dispatchers.IO|Dispatchers.IO> will make use of Loom's virtual threads in the future).