Will be Kotlin more suitable for develop than Scala, in future?


Does Kotlin team have any thoughts about it? Or may be have any further development plan to “beat” Scala?


In what way do you feel it doesn’t already “beat” Scala now? For what it was designed to do it is a better language than Scala. There are things Scala can do that Kotlin doesn’t, but that was by design (to eliminate the complexity of Scala.


We have no specific plans to “beat” Scala or any other language; we’re trying to build a language that solves problems that we feel need to be solved in the best way we can manage. There are teams and tasks for which Scala is a better fit than Kotlin; there are teams and tasks for which Kotlin fits better. This is perfectly normal, and we wouldn’t be able to change this even if we tried really hard.


@yole could you please give some examples of where you think Kotlin is more suitable and where you think Scala is more suitable? They seem to be the clear top two contenders for starting a new JVM project with but it’s very hard to find any good comparison information. I am very familiar with Kotlin and have a minor familiarity with Scala (I don’t think enough to judge tasks where it might be better suited than Kotlin). Clearly the two languages are extremely similair in many ways, I think elaborating more on this specific comparison (Kotlin v Scala) would be a great service to the community.

The information given here is basically a limited feature comparison which doesn’t clarify much. As far as I can tell the two related ways in which Kotlin differentiates itself from Scala are:

  1. Simplicity. Intentionaly limited “feature” set to make a particular codebase more readable to people who aren’t deeply familiar with it. Of course try to balance this by mostly not adding reduntant, infrequently used features.
  2. Leave as much as possible to libraries. This could make Kotlin very versatile and help allow it to flourish as more targets are added to its repertoire (js, native, etc.) because it can more easily blend into the targets paradigms.

Related to blending in with it’s target Kotlin also has better interop with Java.

I would love to hear your take on this or maybe even see a blog post from someone on the Kotlin team comparing it to Scala and discussing reasons why one might choose one vs. the other for a given project. Maybe give us some insight into what specifically made Jetbrains decide Scala was not well suited for their own projects. In @abreslav interview in the Kotlin podcast he said he originally thought the reasons for making Kotlin were “maybe not so great” and referenced Scala many times but never really said what changed his mind.

Comitting to a language for a big project is quite a big deal as you all know and for me personally this sort of meta discussion would really help put what’s left of my concerns to rest.


In our experience, any attempt to compare a language against another language requires making statements about the other language most of which (regardless of their content) end up being disputed by proponents of the other language. And given that our team has a lot of experience using our language and much less experience using other languages, it’s difficult to give enough authority to our statements about other languages.

Because of that, we don’t plan to write any posts comparing Kotlin against Scala or any other JVM language in detail. We’d much rather leave such comparisons to the community.


@dalewking I would suggest that such an evaluation is rather subjective. In different contexts, I could see how I might prefer Kotlin over Scala (one clear case is if I were implementing a Java API; this is something that Scala has not done so well, although, it has improved).

I do consider higher-kinded types… well… table stakes. Also, a system for supporting type classes is also something I tremendously value. Both of these things are absent from Kotlin. Maybe intentionally, sure. Not many people can wrap their head around HK types. But, the point is, most programmers don’t need to understand how to do it in order to take advantage of it. The collections library in Scala has some very positive points, and this is in large part thanks to the employment of higher kinded types and implicit type constructors.

Saying it is better to leave as much to the libraries as possible… well, there are trade-offs. See the 20 some odd implementations of a JSON AST, for example. Things have been getting moved out of the standard library and that is encouraging. Additionally, Scala 2.12 has made some great improvements in calling Java 8 code more naturally.


@yole I think this is probably a good stance. I felt a little frustrated with the earlier Scala comparison because I felt like it was skewed unfairly (probably because the author had more experience with one tool over the other).


I think, the only thing kotlin has to envy about Scala is the type system… I know I know! they are both strongly typed. But Scala has macros, implicits, higher kinds, and probably more stuff to make the most of the compiler and the type system. I mean, I really wouldn’t know how to make a nice and usable HList implementation in Java or Kotlin… I think Kotlin will be over scala sonner than later, but Scala is amazing, and allows for you to make really really really powerful abstractions. For someone who loves to develop in a very modular, abstract way, scala will always be the greatest invention. But that’s not always what the market dictates!


So, do you think that Kotlin is more pragmatic than Scala?