Kotlin makes a splash in the crowded pool of peripheral JVM languages

The enterprise is developing software in a host of languages these days, with a few commonly recognized coding options including Java, Scala, Groovy, Clojure, Python, Ruby, C++ and Haskell. Along with these well-known languages there are a host of DSLs finely tuned to solve a myriad of programming problems. With so many programming languages already available today, why would any organization go forth and create a new peripheral JVM language, especially considering the fact that the Java Virtual Machine is already so crowded?

The truth is that in the world of programming, there is no silver bullet. While many people have a preference for a certain language based on their past experience, there isn't one code to rule them all. That's what the folks at JetBrains discovered when they were looking to migrate to a new language for their own internal development. JetBrains' language designer Andrey Breslav and his team recognized that Scala and Groovy were the only two options up for serious consideration. But neither one really fit the organization's set of constraints. It was time to invent a new language—and that turned out to be Kotlin.

The need for a new language

With Kotlin, you don’t restrict members of your team to using only a subset of the language. Anyone can use any feature.

Andrey Breslav,
lead language designer of Kotlin

According to Breslav, the ideal language needed to meet several very specific criteria. First, it had to be statically typed, performing type checking at compile time rather than run time. Second, it had to be 'toolable'. In Breslav's world, that meant "It had to be able to provide good tooling as part of the language design itself since some things can't be provided efficiently in the IDE."

As creators of the popular Java IDE (IntelliJ IDEA), the folks at Jetbrains know that there are limits to what even the best environments can offer. Some capabilities have to be baked into the language to provide clear access to goodies like refactoring, useful autocomplete, and more. Complex languages like Scala don't necessarily make tooling easy.

As a third point, the JetBrains team also wanted a language that was truly democratic and learnable by the average programmer. Java is already fairly open, but unwary coders may run into trouble when messing around with something like the Reflection API. In C++, macros have been known to be implemented in very unsafe ways.

"There is also a widely accepted idea of restricting yourself to a more approachable subset of Scala. With Kotlin, you don't restrict members of your team to using only a subset of the language. Anyone can use any feature," said Breslav. This democratization might more accurately be termed universal accessibility. But semantics aside, it's sure to be an attractive point for programmers who don't like to be told what they can and can't use in a language.

Prioritizing interoperability

Finally, the Kotlin team knew that their language had to be fully interoperable with Java. Many enterprises already have a huge Java code base. They must be able to migrate as needed, without rewriting everything. With that being said, this new language is not restricted to any particular area of programming. Breslav pointed out, "Kotlin is not a DSL that only some part of the code should be written in and the rest in Java. There's no reason to rewrite it all if what you have is working. But you can write end to end in Kotlin if you are starting from scratch."

One area where this full Kotlin approach can be useful is in mobile development where programmers are still stuck using Java 6. According to Andrey, "Android at runtime is a bit behind compared to what server side people have and it's limited in terms of language features. Kotlin offers very nice features in terms of building GUIs. You have in the code what you used to have in XMLs or somewhere else. There are also lighter APIs in Kotlin vs. Java."

It's evident that not every organization has the same need for a language with these particular constraints. But for those that do, Kotlin may provide that solution that is the perfect fit. JetBrains recommends this coding language as a potential solution for those areas where Java is causing the most pain. This includes applications that feature complex business logic, where code reuse is imperative, and where type safety matters. But, as Andrey made clear, this isn't a language to choose when things are already working. If Scala, Groovy, or old-fashioned Java are still getting the job done well, Kotlin can stay on the shelf.

What do you consider to be Kotlin's most compelling feature? Let us know.