5 years of Kotlin on Android — the extended interviews

We’ve published a celebration post on our blog to recognize the 5 year anniversary of official support for Kotlin on Android.

In the making of that post, I had the chance to interview some great people who were involved in the Kotlin story, and the blog post could only include small bits of what they had to say on the topic. Hence, this post includes some interview material that would otherwise be left on the cutting room floor.

Jeffrey van Gogh

Jeffrey leads a team of engineers at Google working on Kotlin tooling, and he was involved in the discussions around the language from the very early days. He’s also a member of the Kotlin Foundation, a joint effort between Google and JetBrains which safeguards the evolution of the language.

He recalled this about Google’s initial encounters of Kotlin:

We started looking at Kotlin about 6.5 years ago for various reasons. Of course we’re all language geeks who want to learn new languages. We also heard from our customers that they’re starting to use Kotlin even without Google officially endorsing it. We played with it for quite a bit and we were like “Hey, this is actually really neat!”

He also expanded on the cooperation between the two companies.

A few months before I/O 2017 we started talking to the folks at JetBrains about making Kotlin on Android a reality. We wanted to make sure that if we make this a recommended language for Android, it’s supported well. At the same time, JetBrains doesn’t want to see Kotlin becoming only an Android language.

Many other languages have a foundation, and we thought that was a good path for us to take as well. We had to figure out what we wanted to put in the Foundation. We tried to protect the things that we really care about protecting, like making sure that the language ages well. But we have a single person in charge of the language design, appointed by the Foundation, so that we are not designing every language feature by committee.

I’m on the Kotlin Language Committee where we ensure that every time we have to make a breaking change or deprecate something, we do it with extreme care. We want the language to move forward but also to age well. We meet with JetBrains every couple months, look at the issues, and have deep technical discussions.

“The language is still growing and making great progress, adding new features at a good pace, so I think we’re succeeding.”

Egor Tolstoy

Egor is the Kotlin Product Lead at JetBrains, and he reflected on the collaboration efforts from JetBrains’ side.

Development is not the only field of JetBrains and Google collaboration. We work together on product management by sharing research insights and ideas on making the developer experience great. Another crucial joint effort is the Kotlin Foundation, which preserves the Kotlin trademark and works on fostering the growth of Kotlin ecosystem maturity and richness.

He also noted that JetBrains needed to adjust their ways of working to properly support Android developers using Kotlin.

One of the key principles of the JetBrains’ engineering culture is dogfooding. We use our tools daily and test all the features ourselves. When something works great for our purpose, it usually works great for other people. But we are not mobile developers and don’t usually write Android apps. We had to learn how to gather feedback differently — by listening to the community, conducting product research, and working closely with domain experts from Google.

Florina Muntenescu

I spoke to Florina about Jetpack Compose, and she noted the following about its use of Kotlin and the future of UI on Android:

When we decided to start with Compose, we knew that Kotlin was the language to use, not only as the language in which Compose is written, but also as the only language in which it can be used. We made this long-term bet, even if at that time not all developers were using Kotlin. We trusted that Kotlin adoption would grow with time, and therefore Compose wouldn’t have this problem.

We’re not Compose-first yet, but Compose is the future of UI development on Android. Right now, for developers that are starting to learn Android, we’re already recommending the Android Basics with Compose course, rather than the Views one.

“We’ve been telling developers to move to Kotlin for years. Kotlin is here to stay, and Compose is our bet for the future.”

She also described how and why Kotlin makes Compose so great to work with.

What makes Compose really different from the View system is that it’s all based on functions. Functions are a first-class citizen in Kotlin, and composable functions are the core of Compose. This means that composables can easily be reused throughout your application, without having to be tied to a specific class, Activity or Fragment.

Coroutines are used to do asynchronous work in Compose both under the hood and in the APIs that we’re exposing.

You no longer have to have that overhead of switching between Kotlin and XML. Even when you think about large screens, we no longer need to have that switch to XML. With window size classes, you can easily build all of your UI in Kotlin

Yigit Boyar

The next Googler I spoke to is Yigit, who’s been all for Kotlin from the start.

I was a huge proponent of Kotlin for a long time, from the very early days. I started writing Kotlin very early. I believe I have the first commit with Kotlin in AOSP from 2014.

When we started databinding, I initially wanted to write the annotation processor logic in Kotlin, but that was a “no”. But then I pitched that we could use it as a templating engine, and that’s how we started using Kotlin in a very limited fashion.

“A bunch of people knew about Kotlin. We talked about it a lot.”

Slowly but surely, he started working Kotlin into Jetpack libraries as well.

When I started working on Architecture Components, we were able to write the annotation processor of Room in Kotlin, as we don’t ship any of that on the device. The year we shipped Architecture Components was also the same year that we announced Kotlin support.

Google announced Kotlin-first Android development in 2019, but until about March 2020 we weren’t able to use Kotlin in our core libraries. Fast forward to today, now if you want to start a Jetpack Library, you are writing it in Kotlin unless you have a very, very, very good reason not to do that.

We also touched on the problems of having too many concurrency solutions in Java, and migrating libraries from Java to Kotlin.

DataStore is a good example where everything is Kotlin and coroutines. We still have some wrappers for RxJava and Guava to make it usable from Java, but it’s harder to use DataStore without using Kotlin.

In Java you have to use one of the reactive frameworks, but there isn’t a standard one that everyone uses. So what do you do, which one do you support? It’s always been a problem. But we are good today, as everything is in Kotlin. We have coroutines as the recommended concurrency solution, that makes it much easier going forward.

Now we are actively rewriting libraries in Kotlin like we did with Room. We still look for a good reason to rewrite an existing library in Kotlin, and we also keep in mind the binary compatibility rules. The last thing we want is to break people just to convert the language from Java to Kotlin.

Finally, Yigit emphasized that the language has much more to offer than just Android development.

Even though we are very focused on the Android side, we are really trying to make sure Kotlin is adopted on other platforms, too. For example, Google Cloud has Kotlin support now, which was a huge effort at the time.

“Kotlin is very important for Android, but we are not limiting it to Android.”

We want Kotlin to be a top-level language, and that happens only if you have server-side adoption, too, so we are trying to make sure that happens. We’re not short-sighted; we’re not trying to keep it an Android language.

Kevin Bierhoff

I talked to Kevin to learn about how Kotlin is used within Google, both on Android and beyond.

I lead the Kotlin team in Software Foundations, which is the organization that supports the languages we use across Google’s development. We’ve been working to bring Kotlin to Googlers for the last 4 years.

What that means is going through the tools that Google developers use and teaching them about Kotlin. Everything started with making the build system work with Kotlin.

Static analysis is also a large area, which we’ve invested a lot into over the last decade, as a way for us to enforce properties across the entire codebase. For example, we use it to find bug patterns that we want to eradicate. Often that’s about correctness, but sometimes it’s about security or privacy.

The other area we work in is libraries or APIs, going into commonly used infrastructure and making those nice to use with Kotlin. We started with protos, which Googlers ubiquitously use. We designed an API for building protos that takes advantage of Kotlin and provides a nicer experience.

Another big recurring theme is Kotlin coroutines. There is a lot of infrastructure at Google that’s asynchronous in some way. These have traditionally been coded to work with Java Futures, and we want those to be natively supporting Kotlin coroutines now

While we’re celebrating Kotlin on Android today, we are also invested in the language beyond the Android platform.

Initially the effort for Kotlin support within Google came from Android. We didn’t want to just encourage other people to use Kotlin, we wanted to demonstrate that we’re doing it ourselves. There’s always gonna be enthusiasts but a lot of organizations are looking to us to make decisions like whether they should transition to Kotlin.

At this point, we have a substantial amount of Kotlin code in our monorepo, and at a scale that’s large enough that it’s interesting even for JetBrains, to find bugs that they can’t find on their own. That’s something we want to build on and leverage for the benefit of the Kotlin community.

Christina Lee

Speaking of the community, my last interview was with Christina, who works as an Android engineer at Pinterest, and she’s a Google Developer Expert for both Kotlin and Android.

This is how she recalled her first contact with the language.

I walked in on my first day at my new job and someone brought up Kotlin. I couldn’t tell what he was saying because I’ve never heard the word before. I had to go home that night and google it, and suffice to say, we did end up building the app in Kotlin.

When we were debating using Kotlin with Android, we pored over Jake’s document. Back then a lot of people were talking about Kotlin, and that was the document that everybody went to.

We then discussed what it’s like to be a part of the Android and Kotlin communities, and what makes them so great to participate in.

The longer Kotlin has been around, the more I appreciate the community around it and the team building it. The team is so open with the development plan and so open to feedback.

One thing about communities that’s really hard to strike a balance for is pushing for things to get better and giving constructive feedback, but not having the community devolve into snark. That’s really hard to do in person; it’s way harder to do online. What I’ve been so impressed with in both the Android community and the Kotlin Community is that that balance seems to be there.

The Kotlin Community is really incredible for its ability to both give forthright feedback and remain a positive space.

Finally, she summarized the profound impact of the language.

It sounds silly to say it in the context of a new programming language, but technology can really change people’s lives, and it can really make people happier at work. When we were all making that switch from Java to Kotlin, to hear how many people were positively impacted by it, I found that really powerful because it’s hard to find step functions like that in the workplace.

We normally focus on “there’s null safety” or “there’s type inference” or all these other technical parts. But when you take a step back, there’s a whole story in there about all of the people who had their passion for coding ignited or reignited because Kotlin is such a wonderful language.

And you can’t manufacture that, right? You can’t buy people’s enthusiasm, they have to actually feel that way. It’s just so impressive that the team is able to do what they’re able to do and that the community is as good as it is. It doesn’t always happen. I think it’s a really special thing that we have.

We’d also love to hear your stories of learning and adopting Kotlin for Android development! Share them on social media using the hashtag #Hi5KotlinOnAndroid.

Java is a trademark or registered trademark of Oracle and/or its affiliates.