This post is intended to be a sequel to the Talking Kotlin podcast episode that featured Huyen Tue Dao and me. We recorded it in May 2017. If you haven’t given it a listen, go check it out! A quick recap from the conversation: We started using Kotlin in October of 2016, right around when Kotlin 1.0.4 was announced.
Early days
As a team, we knew we liked Kotlin but wanted to vet it a bit more before building new features in it. Writing tests in Kotlin seemed like a low-risk way to see how the team really liked it and decide whether we wanted to invest more in it. Once we became comfortable with it, we kept pushing forward and decided to start building new features in Kotlin. The team rallied behind the goal of: Every new feature in Kotlin. Once we knocked out a few features, we also decided that any updates to old features should require that they be converted to Kotlin before further work was done.
Present – Kotlinize everything!
When we taped the podcast in May, our codebase was about 15% Kotlin. We’re now sitting strong at 30.8%! All current work is being done in Kotlin – tests, updates to old features, and all new features. We shipped our first and major feature (rewriting a socket class) over a year ago in Nov’ 16. Luckily, compilation times are good and have been getting better; Kotlin and Kapt are no longer the culprits behind any large slowdowns.
Not only has our team’s interest in Kotlin grown, but the entire Android community has doubled-down on Kotlin. Google’s announcement of first-party support for Kotlin at Google I/O 2017 drove a lot of attention to the language. Now there are plenty of talks, articles, and tutorials that have hit the net; it is easier than ever before to get started. Working with Kotlin is no longer a fringe skill-set that a few teams can claim to have – it has become a core competency.
If you start digging through our commit logs you’ll find plenty of commit messages that contain “kotlinizing”:
Although we’ve enjoyed the productivity gains we’ve experienced by using Kotlin, there have been a few minor issues along the way:
- Compile speeds are still less than ideal.
- Playing on the bleeding edge is still dangerous (ie: within a day of 1.2.0 coming out, we had issues with the new stdlib components)
Future
More Kotlin! No, really. We love writing Kotlin and are excited about the growing community!
Where to start
- We started with tests because of concerns we had with the compiler performance. But now there has been a lot of work completed by the Kotlin team that has improved compiler speed. We think its safe to start using Kotlin anywhere now!
- Start small; don’t Kotlinize the whole project. Try writing a small feature or two to begin with and get comfortable.
- Play with Kotlin’s functional programming style; you might find that you really like it. And if you do like it, keep going!
- Want more? Go read Dan’s thoughts on “Why Kotlin?”