Kotlin at Ten. Interview with JetBrains’ Roman Elizarov

JetBrains unveiled Kotlin in July 2011, aiming to create a modern, general-purpose programming language running on the JVM as well as on the Web.

Kotlin is a cross-platform, statically typed language with a modern and concise syntax that aimed to overcome Java deficiencies at a time when Java development was stagnating. Among Kotlin key features are null safety, coroutines, data classes, extension functions, and more.

After its announcement in 2011, it took one year for Kotlin to go open source and four more before it reached stability with its 1.0 release in 2016.

Only three years after that, Google made it the language of choice for Android development, which quickly led to over 60% of professional Android developers adopting it. Google commitment to Kotlin got another corroboration recently with the release of Jetpack Compose 1.0, entirely developed using that language and heavily leveraging its syntax capabilities.

Kotlin is not just a language for mobile app development, in spite of its huge success in this arena with over 80% of the top 1,000 apps in the Play Store using Kotlin. In fact, according to JetBrains, over 4,800,000 developers, have used Kotlin for server-side, mobile multiplatform, Android, and front-end development.

The growing adoption of Kotlin is also confirmed by Stack Overflow Developer Survey 2020, which finds JetBrains' language just behind Go and C/C++.

InfoQ has taken the chance to speak with Kotlin project lead at JetBrains, Roman Elizarov to learn more about its past, present, and future.

InfoQ: Kotlin has met with huge success really fast, most strikingly on the Android platform where it has almost replaced Java. How do you explain that?

Roman Elizarov: We count 10 years from the time it was initially announced. If you take it into perspective, you'll see that it has not really made huge success fast. In fact, you'll see a different pattern, that contributed immensely to Kotlin's later success. Kotlin was not developed behind closed doors. For more than half of its life, until Kotlin 1.0 release in 2016, it was constantly tested against the real-life feedback coming from early adopters and adjusted. The stable language that saw the light in 2016 was quite different from the initial ideas that were presented back in 2011. That is the first component of Kotlin's success — Kotlin is pragmatic. It is a language that was not based on a theory, philosophy, or assumptions held by a small group of its designers, but a language based on actual usage data. The overreaching idea was to simplify the day-to-day life of professional developers working on large-scale projects.

There is no single feature that made Kotlin stand out, but the combination of them. From null-safety and friendliness with immutability to concision and efficient functional operations on collections, they all were designed to address concrete pains that Java developers at that time suffered from. However, while the immediate goal was to design a better Java, the inspiration was taken from a variety of languages, both production, and experimental ones.

Since Kotlin's stable release in 2016, the team has taken backward compatibility very seriously, and that is when the real growth and adoption of Kotlin has started. That's the second part of the story. Being a language for industry, the team's strong focus on ensuring backward compatibility had paid off over time.

In hindsight, Kotlin's rapid growth on Android was logical, even though it was never planned for. In 2017, when Google had officially adopted Kotlin, it was already a mature, stable, and battle-tested programming language.

InfoQ: Looking at the present and immediate future, Kotlin further growth appears related to its adoption as a server-side or full-stack language. What maturity level has Kotlin reached to be used in those contexts?

Elizarov: The future of Kotlin on the server-side is bright and clear. That is Kotlin's home turf — the language was originally designed for it. The server-side is quite complex, with lots of existing code that needs to be maintained. That's why Kotlin design was prioritizing and will continue to prioritize good interoperability with existing Java code and libraries. We are glad to see that our efforts are paying off. According to the recent JVM Ecosystem report by Snyk, 18% of JVM developers already use Kotlin. We expect this number to grow steadily. The growth in server-side, of course, will not be as fast as it was in Android, due to the domain specifics, but Kotlin is here for the long run and we are in no hurry.

As a full-stack, multiplatform language, Kotlin is just at the beginning of its road. The whole Kotlin multiplatform was announced just in 2017 and is still experimental. However, we see a tremendous amount of interest and engagements from our community, very similar to the feedback we were getting back then before Kotlin went 1.0. So, again, we are taking a measured approach and are not rushing to stabilize anything until it passed the test of time and got real-life feedback. Based on that past history, as we stabilize various pieces of Kotlin multiplatform, starting from Kotlin Multiplatform Mobile (KMM), we expect the adoption to significantly pick up the pace.

InfoQ: Instead of running the same bytecode on different implementations of a virtual machine, like the JVM does, Kotlin achieves cross-platform support by compiling to different platforms Would you say that, with Kotlin and other languages following the same approach, Java's vision of what "write once, run everywhere" mean is now obsolete?

Elizarov: Java's idea of "write once, run everywhere" had succeeded on the server-side, but had failed to catch on the front-end — both web and mobile. There are just too many platform-specific things that Java had been too slow to adapt to. Even on Android, which can technically run JVM bytecode, not every JVM library will just run out of the box. So, the idea that you can run anything anywhere is indeed obsolete, yet the desire to sharing common code between the platforms is still there. And that's a different goal.

Java's key mistake, in my opinion, was growing too big, trying to standardize and embed into the platform too many things like dynamic code loading, XML parsing, even UI libraries, which did not stand the test of time and turned out to be fleeting fads, not something fundamental. Java modularization has come too late to help. In Kotlin we are taking a radically more measured approach to expanding core language and core libraries. We are making sure that Kotlin will stay relevant for dozens of years to come. Moreover, we don't have illusions that any code could be run anywhere. Our vision is that developers will explicitly keep the list of platforms they want their code to run on in their mind and there will always be some differences between the platforms that need to be occasionally taken into account.

InfoQ: As a server-side or full-stack language, Kotlin has to face stronger competition [than on the Android platform, where it won], including by recently introduced languages like Rust and Swift. How do you see Kotlin playing in this arena? What are its relative merits?

Elizarov: Both Rust and Swift are great languages in their own respect, but I don't see Kotlin directly competing with them full-front, only in some niches.

Rust, in my opinion, is more of a systems language, a safer replacement for C and C++. In Rust, you have precise control over memory and other resources, and more abilities for low-level performance tuning of your code than in Kotlin. You can write great application software in Rust, but it will come with a steeper learning curve for developers, more effort, and more verbose code to tell Rust compiler what exactly you want to do. Kotlin's approach is quite the opposite. Kotlin's goal is to completely remove any ceremony, including memory management, from the code, and let application developers focus on the substance of their code — the business logic they are writing, even if it means sacrificing some runtime performance.

Swift is different. Swift has a modern look and feel, but it still continues the tradition of Apple's Objective-C, having many features and unique design choices that few modern languages outside of Apple's ecosystem make. That alone makes it a niche language. Moreover, Apple, being Swift's creator, does not seem to be genuinely interested in Swift's future on other platforms, or so it seems to an outside observer. For Kotlin it means tough competition with Swift for the minds of developers on Apple's platforms, but little concern for all other platforms that Kotlin targets.

InfoQ: Kotlin is here to stay. How would you like to see Kotlin evolve in the next ten years?

Elizarov: Our main focus for the next ten years is on the multiplatform ecosystem. We still have to stabilize our core parts of it, both compilers and tooling, and then help the community with all the domain-specific libraries that are needed for an ecosystem to thrive.

On the language itself, it is all about staying relevant and keeping up with all the modern trends and innovations. We are currently experiencing a revolution in UI. Reactive frameworks take the lead and Kotlin is riding this wave, fully embracing Jetpack Compose as Kotlin's modern UI paradigm. As reactive programming takes hold of the minds of developers, the ergonomics of working with immutable data becomes a full-front concern for the language and that is one of the areas we plan to be investing heavily in the next ten years. I personally do expect a similar change to happen on the server-side later in this decade, with the focus shifting from mutable data to immutable, from imperative to more functional reactive code.

Working with data is the general trend here. As our information systems become more complex, we often find ourselves having to deal with less structured and more evolving data structures. So far, dynamic languages like Python and JS had reaped the benefits of this transformation by offering developers an easier way of working with arbitrary data at the cost of producing code that's harder to scale and support at the industrial size and complexity. We are looking at ways to combine some of those approaches with Kotlin's strong static typing to give developers better tools for all their data manipulation needs. We are particularly interested in the growing field of data science and will continue improving in this area.

As Kotlin expands into more domains inside and beyond server-side and mobile, we cannot ignore the need to support better meta-programming facilities. Many domains want to have their own domain-specific tweaks or extensions that simply do not fit into the rigid framework of your usual libraries. Kotlin was originally designed to be a well fit for domain-specific languages (DSL) with its receivers, builders, and inline functions. But we are now looking beyond that. Both expanding the capabilities of Kotlin's inline function and providing facilities for compile-time computation as well as working on compiler plugin APIs for more radical domain-specific extensions to the language.

A few months ago Kotlin reached version 1.5, which introduced interop support for a number of recent Java features, including record classes, sealed interfaces, and inline classes. Additionally, the Kotlin compiler switched to a new JVM intermediate representation with the aim to improve performance and provide the foundation for new language features. Kotlin can be installed as part of IntelliJ IDEA and Android Studio or cloning its GitHub repo.

About the Interviewee

Roman Elizarov is a Project Lead for Kotlin at JetBrains and currently focuses on the Kotlin language design in the role of Lead Language Designer. In 2000 Roman Elizarov had graduated from St. Petersburg ITMO and started his career as a professional software developer. During his undergraduate study, he participated in International Collegiate Programming Contests (ICPC). Since 1997 and until now Roman serves as a Chief Judge of Northern Eurasia Region of ICPC. He also maintains his academic ties and teaches a course on concurrent and distributed programming at ITMO. Roman Elizarov had worked for most of his career at Devexperts, where he designed and developed high-performance trading software for leading brokerage firms and market data delivery services that routinely handle millions of events per second. He is an expert in Java and JVM, particularly in concurrency, real-time data processing, algorithms, and performance optimizations for modern architectures. He has been working on Kotlin in JetBrains since 2016 and has contributed to the design of Kotlin coroutines and the development of the Kotlin coroutines library.