Scala and Kotlin are the two contenders for the Java throne. At the very least they are the two main languages to consider using in a JVM based application.

They aim to solve the same problem: providing a better Java but they do it in a very different way:

Scala has been designed in the Academia, Kotlin in a leading software company. The background in which they are born explain most of their differences. Scala has been born to try some cool ideas on functional programming and mixing different paradigm. Kotlin is about solving practical problems. Kotlin designers cared about compilation times and great tool support, because those things matter to programmers, even if they do not sound exciting for other language designers. A great merit of Scala is that it proved to be possible to build another major static language for the JVM. It made clear that the JVM was flexible enough to allow language designers to benefit from it. Kotlin arrived much later. At that time people were not excited by the idea of having a new JVM language, they started caring about the practical aspects.

In this article we are going to compare Kotlin and Scala mostly for their uses, not their technical features. We are just going to make a general overview of the features of these two languages, and we are mostly concentrating on what they are designed for.

Is There Anything Wrong With Java?

Both Kotlin and Scala runs on the JVM and compare themselves to Java. This begs the question: is there anything wrong with Java?

Well, certainly Java did a lot of things right. It was an evolutionary language, rather than a revolutionary one. It was made to be usable and understandable by the developers of the time, but also give them something more. Its promise: Write once, run anywhere is alluring now as it was at the time.

In fact Java is probably the most used programming language in the world. Java is also arguably the most used language in the enterprise world and the most widely taught language in computer science courses.

So Java is great, just like C is great. But just like C, Java is old.

And although Java has evolved more than C, and luckily in a more organized way that C++, it is lagging behind many other languages. It is still certainly good enough for daily use. And many developers are happy with Java. But many compare it unfavorably with C#, which is a language with similar purposes. Or really almost any other modern language.

It is not a secret that many developers, and companies, want something more productive and I dare say fun to use. There is a lot of technical criticism of Java itself and a lot of baggage in the language which limits what it can be made easy to use. This is the curse of success: so many people use it that the designers cannot really change the fundamentals even if they had discovered they were wrong about something.

Why Scala And Kotlin

For many years developers have built new languages on the JVM. Many of these languages attempted to be a mix of improvements over Java and offering something more than Java. That is to say many tried to improve the developers productivity and experience, while doing the same things that you can do with Java and/or also tried to make something different, like a dynamic language or one similar to Lisp.

Scala stands for Scalable Language, a language designed to scale with the needs of its users, while Kotlin is the name of an island, just like Java.

We picked Kotlin and Scala because they are both quite popular, statically typed languages and good representatives of two approaches: Kotlin is purposefully made as an improvement over Java while Scala is a different language altogether. Kotlin gives you everything you need, Scala gives you everything you may want.

Scala has the right features, but its most obvious deficiency is very slow compilation

You can already find articles of people that decided to move from Scala to Kotlin. In some ways the creators of Kotlin did that too. In fact, the quote comes from an interview with the lead Kotlin developer that explained one of the reasons because they decided to create Kotlin. The other one, of course, was to create a better language than Java, but that was still compatible with the JVM.

This does not necessarily mean than Kotlin is better than Scala, of course. On the contrary it means that Kotlin designers think that Scala is a good language. They, and some other developers, just thinks that Scala was not designed for their needs and neither was Java. So they made Kotlin.

A Comparison Of A Few Features

As we said in the introduction we are not listing all the technical features, nor we are looking at the syntax. We think that too much details can be confusing especially without a context. Furthermore nobody choose a language with a checklist. Nevertheless it is important to see some significant features and the approach the languages pick.

Object-oriented

Java is a language designed for object-oriented programming, but not everything is an object. The basic types, like numbers, are represented as primitive types. In Scala and Kotlin everything is an object and can be accessed as such. This is not necessarily a deliberate choice, since there is a slight penalty for using reference types instead of primitive, but it is due to the fact that in JVM you cannot define value types. So to get the advantages of a smarter type systems you can only implement it with reference types.

Scala and Kotlin supports also other programming paradigms. Although Kotlin remain mainly an object-oriented language it include basic aspects from all programming paradigms that are advantageous in daily programming.

Functional Programming

Kotlin supports fundamental functional features, such as lambdas and higher order functions. But it does not fully support functional programming paradigm. As always, it goes for the pragmatic bits that can be useful to the average programmer, without requiring a PhD in Computer Science to be used proficiently. For example:

independent (top-level) functions are fine and you do not need to make utility classes to contain disparate functions

Kotlin defines expressions rather than statements, so you can assign to variables things like the result of if

you can easily define immutable data with val , instead of var . No need for modifiers like final

Scala supports equally well the functional and object-oriented programming paradigms. It was designed with this goal in mind, and it has most features that you will find in Haskell, but not in Kotlin or Java, such as currying, memoization, partial application, type classes… It has the whole package, so to speak.

Small Things

Every language can be different. Both Kotlin and Scala have many productivity features that are standard in new languages, but they were not so when Java was created, things like type inference and quick ways to create a singleton or a data class.

Kotlin

Given the focus of the language, Kotlin has all the essentials and little else, although it also has first-rate support for null-safety and interesting things like smart casts. Smart casts means that if you check the type of a variable that is automatically cast to the new type, of course if it actually is a variable of that type. Generally speaking Kotlin uses very well its set of features, rather then adding more things. For example you can overload operators, but only the basic operators that are already in the language, you cannot define new ones.

Kotlin also ease the creation of an internal DSLs, or fluent interface. It does that with lambdas and the help of some syntactic sugar. Like the fact that the last argument of a function, if it is a lambda, can also be put outside of the parentheses. This is useful to reduce the need for complex string interpolations. For instance, this example uses a library to create HTML.

createHTML().table { for (language in languages) { tr { td { +language.name } td { +language.popularity } } } }

Scala

Scala instead has all you may want from a language that need to be both functional and object-oriented. Although it has some small flaws of its own, for instance, the managament of null-safety is less efficient and natural than in Kotlin.

Scala also excels in the creation of complex internal DSLs, by including macros and the chance of creating custom operators. Using Scala you have great freedom and many chances of hang yourself. For example, many developers lament the overuse of arcane custom operators whose purpose is not really clear from the code itself.

It only a slight hyperbole to say that if you imagine any construct you can do it in Scala. So you have to pay attention to the imagination of your developers, and their competence.

Interoperability With Java

Kotlin Was Designed To Work With Java

Kotlin is a language created to maintain compatibility with Java. It even has functionalities to facilitate interoperability with Java, like making easier to call Kotlin idiomatic code from Java. So you can keep developing legacy software with Java, but creating new ones with Kotlin.

One reason because Kotlin is so popular on Android it is due to its compatiblity with Java 6, which is largely the current Java version of Android. So Kotlin brings some features that are already in Java 8, but are not available to Android developers.

Interoperability with Java is not an accident, or simply what you can get by using a language that runs on the JVM. JetBrains designed Kotlin aware of the current Java ecosystem and situation. They tried to bring the most value in the way that was easier to use. This compatibility get down to the structure of the bytecode itself. And was one of the reasons that lead Corda to pick Kotlin over Scala.

Scala Can Work With Java

Scala was created to run on the JVM platform, for easier deployment, but compatibility was not really a primary objective. This starts with the technical side and keep going with the language features. For instance the recent versions of Scala requires Java 8.

This, coupled with the features of the language, means that if you want to develop with Scala going back-and-forth to Java is hard and not really an intended use case. Working with an existing Java codebase? Yes, you can. Keeping developing Java software with Scala? Not really a good idea.

Compatibility is also made difficult by the fact that Scala support functional programming as well as objected-oriented programming. If you use its advanced functional features you cannot really do much with that in Java. And, even if you could, your Java programmers might not know how to use them.

Different Philosophies

Many successful languages have precise objectives and a specific philosophy of what programming should be. Kotlin and Scala are no different. Kotlin wants to be a better Java, while Scala plans to be much more than Java.

Kotlin Is A Better Java

You could argue that Kotlin has fulfilled its original objective: it became the first language to be officially supported for Android development, other than Java. This is undeniably a great achievement that prove a couple of things: the Java community loves Kotlin and it is easy to introduce Kotlin to Java developers.

Kotlin is a pragmatic language designed to improve productivity and being easy to learn for Java developers. It is mainly designed to be Java like, but with a bit of C# and even Scala, on top of the Java model. It adds features that Java programmers want, like lambda and basic functional features, and simplify life, like smart casting and non-nullable types. Kotlin additions in many cases are what is usually called syntactic sugar. A more concise way to express common patterns used by developers.

While Kotlin offers some support for functional programming it really does it to accomplish easier procedural or imperative programming. For instance, individual functions can now be first class citizens of the language. Kotlin prefers to be simple rather than being formal.

Scala Is More Powerful Than Java

Scala never tried to do any of that that. It was designed to be more powerful than Java. Or more generally, a better language than Java. Scala was designed to do things that Java could not.

Scala offers great support for advanced functional programming, in fact functional programming is a first-class citizen just like object oriented programming. This adds complexity and make Scala a famously hard language to learn and use. This is not strictly a flaw of the language, you can do more, so there is more to learn. You can mix paradigms and thus you must know them all.

This can be an advantage in the rights hands and a disadvantage in the wrong ones. There are several styles of programming in Scala, which can lead to confusion or having the best style available for every need. In any case this lead to higher costs of development and higher wages for good Scala developers. Which can be a good or a bad thing depending on who you are.

The World Around The Languages

Community

Scala has a larger community, if nothing else because it has been around longer. Unless we are talking about Android development where Kotlin probably has already the upper hand. Just look at the 2017 Google I/O to see the enthusiasm with which Kotlin was received.

The relative lack of native libraries is somewhat mitigated by the excellent Java compatibility. But robust libraries with idiomatic Kotlin code are not always available in Kotlin or they are not as deeply developed as the ones for Scala and Java.

Documentation And Easy Of Learning

Both languages have a good documentation, but surprisingly the Scala longevity might be a problem here, because some parts “are in state of flux” (for example the Scala Wiki) or might be outdated now that the official Scala website has been updated. Furthermore you must train developers in Scala and train them in your style of development. You cannot just pick some Java developers and give them a few days of training. Actually, if you pick a typical Java developer you might even have to train him in functional programming.

You can do that with Kotlin. Corda actually did just that:

Excellent documentation and tiny standard library makes it a very fast language to learn. We do not explicitly advertise our positions as needing Kotlin experience and have been hiring people who didn’t know it already, with ramp-up times in the range of 1-3 days before the new team member is producing idiomatic code.

Kotlin is easier to learn and easier to try, it has a great online test environment with examples and which can even convert Java code. So you can instantly see how to do the same stuff you do in Java.

Tooling

Both Scala and Kotlin are statically typed languages which allows a whole class of compiler checks and static analysis tools. So the potential is similar. Having said that, tooling is better for Kotlin, which is unsurprising given that is created by JetBrains, the famous software house of programming tools. As for the documentation, it is not really a case of Scala is bad, but Kotlin is awesome.

Previously the official Scala website offer an Eclipse-based IDE. We reported this fact and that is why you are going to see mentions about it in the comment. Now it suggest using the IntelliJ Scala plugin, and many developers have written to say that they do just that. So there is a good IDE for Scala.

However Kotlin is already integrated in IntelliJ IDEA and Android Studio. It also has a plugin for Eclipse. Furthermore IntelliJ IDEA has also the same conversion tool and examples available online, so you can easily convert Java classes and learn the language with interactive examples. You can also use a standalone compiler if you need a more advanced integration with your workflow.

Summary

Kotlin design seems to take an holistic approach: its authors considered how each design decision affected the whole development experience. Was a feature really necessary or were there alternatives? Would that choice make the compiler slower? Would it make more difficult to provide good tool support?

Scala designers seem not to bothered by pragmatism, as they follow another great idea. Scala reminds me of C++: there is always place for one more feature. Sure, they say that you can adopt your own subset and reduce the complexity of the language as it is used in your organization. It could work in some places, but I am not sold to the idea for everybody.

Many people moved to Scala with hope for a better language and unsatisfaction with Java. Most of the people that had the first motivation are happy with Scala. Many of the ones that were simply unsatisfied with Java are a bit perplexed by the complexity of Scala. It is not the right language for them. It is simply something different from plain old Java.

Kotlin is probably a better language for them. Every Java developer can easily pick Kotlin, not so for Scala.

If you need a Java-like language that is more productive than Java itself, you should go with Kotlin. If you need Haskell plus Java, you should go with Scala.

We hope that this pragmatic comparison has been useful. But if you want to get a more technical comparison and a look at the syntaxes of the two languages we suggest you look at Scala vs Kotlin, or a series of three articles by A Java geek.