Talk

---

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. 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. 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. Google is getting behind Kotlin because of its vast and growing ecosystem, which can be seen on developer.android.com and kotlinlang.org. 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. 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. 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. 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. 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. 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. 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. 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.

---