Google's Journey from Java to Kotlin for Server-Side Programming
Conference (INTERMEDIATE level)
Room 5
Score 0.15
Score 0.15
Score 0.16
Score 0.16
The match becomes increasingly accurate as the similarity score approaches zero.

Kotlin is now a recommended programming language for server-side JVM usage at Google, while still providing access to a large existing Java ecosystem.  With over 11 million lines of Kotlin code at Google (across server and Android), we've done a number of things to ensure our developers are successful with Kotlin.  This talk will explore the challenges we faced, and the reasons we're adding Kotlin as an available language and how we've made it a successful change.

James Ward

Professional software developer since 1997, with much of that time spent helping developers build software that doesn't suck. A Typed Pure Functional Programming zealot who often compromises on his ideals to just get stuff done. Currently the Kotlin Product Manager at Google.

Brad Hawkes
Google, Inc.

Brad Hawkes has been a Software Engineer at Google for 15 years, most of which has been developing server side Java and now Kotlin. Brad has been leading the integration of Kotlin into Google's standard serving framework and working to increase internal adoption.

John Pampuch

John leads Google’s Internal Production Programming Languages team. Including the Java and Kotlin Teams. John has held various engineering and management roles at Google, Sun, Oracle, Adobe, Azul Systems and others, including, at Sun and Oracle, John led the JVM (Hotspot) group.

John is primarily a Java developer, but has also written his fair share of bugs in C, C++ and other languages.

In a past life, John invested a small fortune into Legos but today those mostly sit on a shelf in the garage.

Generated Summary
WARNING: This summary was generated using GPT based on the transcript, as a result spelling mistakes and more importantly hallucinations can be present.

Google's Transition to Kotlin
Using Java Effectively
Google has been using Java for many years and has built tools to make it work at Google scale. John Pampwitch and his team help developers use Java effectively by integrating with the build system, code review system, and IDE. They are also responsible for migrating all the code from Java 8 to Java 11. They use tooling to automate the migration process.
Kotlin for Android Apps
Five years ago, the Android team announced that Kotlin would be used for Android apps and now 95% of the top 1000 Android apps use it in some way. Google has also been looking into how to use Kotlin for server-side programming over the past few years, and now supports it.
Kotlin Codebase at Google
Google has been using Kotlin for a few years and it has now gone GA on the server. Thousands of engineers at Google are writing Kotlin code, but teams are not forced to use it. The mono repo for Kotlin code is up to 11 million lines, and use of Kotlin is growing quickly. 70% of developers whose primary language is Kotlin say that it makes them more productive, and 80% of server-side Kotlin developers are satisfied with it. There is also a 20% less likely chance of crashing due to null safety. There is no degradation of productivity when working with a mixed Java and Kotlin codebase.
Advantages of Kotlin
Google is getting behind Kotlin because of its vast and growing ecosystem, which can be seen on and Kotlin is a popular programming language with many great features such as null safety, DSLs, type inference, and data classes. Google has a large Java codebase and is beginning to use more Kotlin. To take full advantage of the language, they had to create Grpc Kotlin and Protobuf Kotlin.
Challenges of Kotlin
Although there are great features in Kotlin, it is not free and there are challenges to adopting new technology. Examples of this include making sure that Protobuf Kotlin produces compatible Java objects and making sure that Optional behaves the way developers want with Kotlin.
Asyncronous Programming
Brad has worked with Kotlin on the server side at Google, taking advantage of the interop capabilities between Java and Kotlin. This has allowed them to incrementally incorporate Kotlin into their existing codebase without needing to rebuild everything from scratch. Asynchronous programming is also important for Google due to the need for a large number of threads to get good utilization. Little's Law is also a factor as Google has a lot of large fan out operations. RPC graphs allow us to coordinate requests with a low latency environment, but they are limited in quantity due to expensive threads and the need for stability. Async frameworks can be difficult to work with, so Google has created alternatives such as producers, promises, and RX Java. Co-routines are better than Java concurrency frameworks and enable suspending functions that can be paused to wait for RPC returns.
Kotlin Co-routines
An example of this is a server sending emails to a group of people using the producer framework. This code discusses the use of asynchronous functions, graph API calls and Kotlin co-routines to send group emails. It explains the ceremony involved in using these functions and how Kotlin's auto-wiring works to create an optimal schedule. However, there are issues with calling Kotlin suspend functions from Java, and difficulties with thread locals. The article also touches on how thread safety is not discussed in an enforceable way, and how developers are often not aware of whether their code is thread safe.
Static Analysis
Kotlin is introducing new primitives for synchronization and multi-threading which makes it easier to share data. However, this also makes it easier to make mistakes and cause problems. To address this, static analysis heuristics are used to ensure thread safety of data objects. Loom is an exciting new tool for threading, but it won't be available on all platforms. Co-routines provide an alternative that will help companies be Loom ready when it is available.
Evaluation of Kotlin
Google is transitioning from Java to Kotlin for software development, but there are many challenges that come with this transition. Motivating engineers to make the switch, training them on the new language, and making sure they are aware of it are all challenges. Additionally, integrating Kotlin into Google's existing ecosystem, creating documentation and best practices, and setting standards all take time. Finally, static analysis is an important tool but has to be re-implemented for Kotlin and is more computationally expensive than the existing Java version.
Cost of Mixing Java and C++
Google conducted a study to evaluate the cost of mixing Java and C++ in the same project, which showed that there was a significant overhead. Another study with Kotlin had a different outcome, with low impact and even improvements in some cases. It is speculated that this is due to Kotlin's ecosystem being easier to adopt.
Measuring Developer Productivity
To measure developer productivity, Google looks at developer satisfaction, as well as lines of code and change request rates. Ultimately, Google found higher developer satisfaction, productivity, reliability and the ability to adopt incrementally when using Kotlin. Google is transitioning to Kotlin for software development, due to its many features, vast and growing ecosystem and higher developer satisfaction. Google has created tools to make the transition smoother, such as Grpc Kotlin, Protobuf Kotlin, producers, promises, and RX Java. Despite the challenges that come with transitioning from Java to Kotlin, such as training engineers and creating best practices, Google has found higher developer satisfaction and productivity with Kotlin.
You can also ask questions on the complete talk using Devoxx Insights