Kotlin vs Scala: Which Problems Do They Solve?

Kotlin vs Scala: Which Problems Do They Solve?

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:

  1. 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.
  2. 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.

100+ Resources to Learn Kotlin

Receive over 100 resources to learn Kotlin in the right way.

You will receive the guide in your inbox, ready to be read on any device you want, when you have the time.


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

Scuola di Atene a painting of Raphael

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 casted 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

People working together

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

A representation of Earth half in daylight and half in the dark

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.

25 replies
  1. alex
    alex says:

    What a bunch of biased nonsense.

    Scala created by people with dream.
    Scala is full of innovation from best minds.
    Scala has its own area of application (big data and other cool stuff).

    Kotlin created by people with ambitions. Read interview with JetBrains CEO.
    Kotlin is compilation of (best) modern practices. Copy-paste.
    Kotlin is leading (primary soon) language for android development and “better java”. Boring.

    Reply
    • Federico Tomassetti
      Federico Tomassetti says:

      Hi Alex, thank you for your comment.
      Well, we strived to be objective, but of course the fact we created a website named “SuperKotlin” is an indicator of where our preferencies lie 🙂
      Personally I have used Scala in a few projects, and I was really wanting to like it, however practical things like the compiler speed or the editor support prevented me to get really productive with Scala. I tried again and again every 6 months or so until I gave up. For me using Kotlin was a very different experience.
      Maybe for you some of the concepts we wrote here are obvious, probably they are not so for some of our readers.
      However if you have any idea or suggestions to improve the article and give a better picture of the differences between Scala and Kotlin I would be happy to read them.

      Reply
  2. ScalaFan
    ScalaFan says:

    Scala is not an ‘academic’ language or ‘too hard to learn’. We have a successful large team filled with people from all different backgrounds using it just fine, ‘advanced’ features and all. Languages with design deficiencies will always appear ‘simpler’, but applications written in them will become more complicated. Hence, our Scala applications are very easy to read and jump into, even for people new to Scala.

    Kotlin will suffer the same fate of large monolithic java applications because it made so many of the same design flaws.

    Reply
    • Gabriele Tomassetti
      Gabriele Tomassetti says:

      We didn’t say that the language was academic, but that it was born in academia. And that is simply a fact, though of course we can argue about its meaning.

      Scala is certainly a successful language that can be used profitably in some environments, but no language is perfect. Just like for C++, we think it is fair to say that is harder to use than the typical programming language.

      Because you can do so much with it, it is easier to do something sub-optimally, it is harder to find the good patterns and it is easy to have mismatching styles. Given that you are a fan of Scala you will be aware that this is a common criticism with Scala. You might find it unfair, but many people think this way.

      For example, a common criticism is that some libraries uses the power that Scala gives them to make very obscure custom operators. Probably the original developers find these concise operators a good thing, but some user find them obscure. This mismatch of expectations and styles is more common with languages like Scala.

      Reply
      • Ivano
        Ivano says:

        Please, I find the article interesting enough, yet this comment about obscure operators denotes a relative ignorance of the scala community and its progress.
        The dispatch library was considered flawed and cryptic by so many people that almost every existing scala project from then on take extreme case to avoid using symbolic operator other than in specific and well justified cases (especially DSL): this has been considered a best practice for years now!
        Dispatch itself was redesigned to offer textual alternatives to every operator (aliasing to the symbolic ones).
        The most visible outlier in this regard is scalaz, which is outstanding in many ways in the scala ecosystem.
        So please just stop referring to a situation that was corrected years ago (the quora link you provide has the most recent answer dating 2014) because it doesn’t reflect the current scenario of scala libraries in any way.

        Reply
        • Gabriele Tomassetti
          Gabriele Tomassetti says:

          Even if you disagree with that specific example I don’t think it invalidate the general point.

          Having said that, we do not use Scala professionally right now, but we talked with people that do. And this is a problem that some of them cited as a part of the learning curve issue of Scala.

          If you are training a new developer in Scala you might also have to explain to them how they should use this or that feature of Scala. And why, for instance, they should not be too concise with their choice of custom operators. That is because conciseness might be better when you are writing code, but it is worse when you are reading it.

          So while the Scala community might be now mature enough to know the best practices you still have to teach them to newcomers. The same happens with C++, there are best practices, but there are developers out there that do not know them.

          Reply
          • CodeNinja
            CodeNinja says:

            So bottom line is – Kotlin is for stupid developers. Nothing new to learn, no complex theories and ideas to understand, no progress. Is that what you wanted to tell?

          • Federico Tomassetti
            Federico Tomassetti says:

            In my opinion prefering simplicity and understanding the cost of complexity is a characteristic of someone who is not stupid at all.
            Learning is a cost but it is also a barrier for the adoption of a language. Even if a single developer would be willing to do no matter what to learn a certain language, that cost would keep many others out, limiting the number of libraries written in that language, the investments in tooling and hampering the development of the community. So learning cost is a crucial factor to consider and indeed all successful languages built on languages who preceded them to reduce such cost.
            Kotlin has a lot of interesting features but I think its creator found a balance between introducing new features and the cost they would have brought in terms of complexity. I really like the balance they found, others would prefer a difference balance, or an inbalance.

  3. Matthew de Detrich
    Matthew de Detrich says:

    Disclaimer: Scala developer here (also repost from reddit)

    Considering this is coming from a Kotlin blog, this is fairly neutral however the thing that really stood out is point about null safety checking. At least in the real world, Kotlin is all over the place when handling optional values (null vs the new Optional which Java has introduced and the 5 or so different ways you can annotate null safety checks so its compatible with the Java ecosystem).

    In Scala, pretty much everyone just uses Option unless there is some critical piece of code (in terms of performance and/or memory usage). Any Java library that is used in Scala has its results wrapped in Option (which returns None if the value is a null). Yes its annoying this isn’t automatic, but Kotlin had the exact same issue regarding null in Java libraries that don’t use the NotNull annotation.

    Which ultimately means in Scala its consistent, its pretty much always Option and no one really works with null where as Kotlin has to deal with the hodgepodge of putting effort to make null checking better (even though you couldn’t do it completely because its impossible to do so) and now having to deal with Java’s new Optional

    Reply
    • Gabriele Tomassetti
      Gabriele Tomassetti says:

      This is quite an interesting comment.
      I think that this blog post about null safety in Kotlin is a balanced one. All approaches have flaws.

      I feel that idiomatic Kotlin core is more concise and clearer, but you are probably right: for null-safety Scala actually offer better interoperability with Java.

      Reply
  4. Nicholas
    Nicholas says:

    Could you actually compare Groovy vs Kotlin ?
    I think comparison with Scala is not very meaningful.
    Moreover, I see Kotlin is gaining popularity and it is to me so strange that in none of the articles there is a single reference to Groovy… Because I personally think Kotlin is basically statically typed Groovy. A lot of influence from Groovy.
    Groovy has optional static type support, been around much longer.
    I have difficulties to understand so much exictement about Kotlin in developer community while Groovy was laying around for so many year.
    I think there is a very bad prejudice (stemming from poor education) against dynamic typing…

    Reply
    • Gabriele Tomassetti
      Gabriele Tomassetti says:

      You are right in saying that Kotlin is influenced by Groovy, the developers themselves have said it.

      I don’t think that there is prejudice against dynamic typing, most people would say that development is generally quicker with them. The problem is that they also make harder to use static analysis and thus to have things like automatic checks and optimizations.

      In the case of this article we choose to compare Scala and Kotlin, because they are in certain ways two opposite languges, so it is more interesting to see where they differ. On the other hand, as you said, Kotlin and Groovy seems more similar.

      Reply
  5. Tianhao
    Tianhao says:

    It’s definitely a biased article from where it posted.

    The author definitely doesn’t use Scala 2.12 and still use the old eyes to say Scala compilation time is slow.

    Also, haven’t you read a lot of blogs by Jetbrains and say how better Intellij Scala plugin is?

    Reply
    • Gabriele Tomassetti
      Gabriele Tomassetti says:

      We didn’t say that compilation time is slow, we quoted one of the developers of Kotlin that say it was one of the reasons because they choose to create Kotlin. This was the experience that he had at the time.

      You are right that there is a Scala plugin for IntelliJ, but we concentrated on the default IDEs. We thought that going too deep in an analysis of tooling would have been counterproductive. Most people that read this article are interested to know the feel, features and companies that support of the two languages.

      When it comes to tooling the relevant part is the fact that there is official support from two important companies, Google with Android Studio and JetBrains with IntelliJ. This is important if you a company that want to choose to develop with a specific language, because it gives some assurance that there is going to be support for some time.

      Reply
  6. Stephen
    Stephen says:

    It seems to me like Kotlin only improves the most basic issues. Like null checking. But not powerful enough to provide a generic way to achieve safety and power in other contexts, like scalaz or cats validations. Is Kotlin is probably good for you if you are scared of the word ‘Monad’, but if you are happy to learn a little, you find they are easy and powerful.

    Maybe Kotlin will get a for comprehension to…

    Reply
    • Gabriele Tomassetti
      Gabriele Tomassetti says:

      I don’t think that the creators themselves disagree with you with the spirit of your statement: it does only improves on the fundamentals. And that is exactly what it wants to do. That is exactly what many Java developers need.

      If you are happy with Scala you should probably not use Kotlin. But most people do not need all the power of Scala, they need the power of Java, but easier and more productive.

      Reply
  7. Serge Bureau
    Serge Bureau says:

    I am sorry, but Kotlin is nowhere close to the level of Scala.
    Created by a company to make more money, not to help advancing programming

    Reply
    • Federico Tomassetti
      Federico Tomassetti says:

      Well, I do not know if and how much money Kotlin has brought to the company, but honestly it should not be a factor. The only question is which language benefits the most developers in different situations.
      For many the answer is Kotlin. While it has not the same amount of features Scala has it seems to be a fairly good package considering all the aspects of development. Of corse some developers in some context will be much more happy with Scala, but I do not think it depends on who created the language.

      Reply
    • Rohi
      Rohi says:

      and Typesafe (now Lightbend) doesn’t want to make money? When your project grows big enough, you’ll NEED to buy their support. Especially if you’re invested in their tech stack (Play, Akka). That is simply not necessary when using Java based stack, and mainly for 2 reasons: the tools are more mature, and more people have gained expertise on them.

      Reply
  8. Petr Novak
    Petr Novak says:

    I can understand the merit to move from Java 6 to Kotlin for Android development. But considering that Kotlin improves on few fundamentals I’m not convinced it is a great benefit to move from Java 8 to Kotlin. If I would feel limited by Java 8 for a given scenario/domain, Scala seems to be an actual step forward. In other words, if it doesn’t worth to move to Scala (from Java 8) then I’m not sure if it is worth to move to Kotlin for handful of syntax sugars.

    Reply
    • Gabriele Tomassetti
      Gabriele Tomassetti says:

      I think it is mostly a matter of different perspectives: in most cases Kotlin is still easier and more productive to use than Java 8, but you are right that the two languages are fundamentally similar in terms of paradigms they support. Of course the same could be said about Java 8, Kotlin and any modern language, like for instance C#. More or less you can do the same things with all of them.

      Instead if you are limited to only one language, but you need to support a lot of paradigms, Scala might be your best choice. But this situation happens quite rarely. Most of the time you just need a productive language that supports the paradigms you need. And in that case Kotlin seems a better choice than any Java version.

      Reply
  9. Kota Mizushima
    Kota Mizushima says:

    Hi. I read your article yesterday via twitter. If you wrote just impression, I’ve nothing to say. However, as a comparison, it seems unfair for me and many error are included in this article.

    1. Scala was designed to work with

    You say “but compatibility was not really a primary objective”. It’s totally wrong. Scala was designed to work with Java as a truth for solving practical problems.

    * Scala’s type system is designed to work with Java’s type system and Kotlin inherit Scala’s approach basically (generics, variance, type hierarchy, ‘no static’, etc.)
    * Scala’s compiler support Java/Scala mixed project (also in sbt) even if there is mutually recursive references between two language
    * Scala class can extend Java class and Java class can extend Scala class seamlessly
    * sbt depends on maven ecosystem and can use easily maven artifact
    * Existent Java libraries can be easily used from sbt
    * Scala 2.12 requires Java 8 because compatibility with latest Java SE is important. For example, Java lambdas can be easily used from Scala 2.12 and default methods in Java 8 is natively suppported in Scala 2.12.
    * …

    2. Scala also has good IDE support

    IntelliJ IDEA Scala Plugin (by JetBrains) is mainly used for writing production codes and it’s quality is very good. Since Scala IDE for Eclipse is not used in ‘real’ production codes in most cases, IntelliJ IDEA Scala Plugin is de facto standard Scala IDE.

    3. Documentation was improved significantly

    See: http://docs.scala-lang.org/

    4. Should not ignore Scala community’s progress

    For example, overuse of arcane custom operators is seen as ‘bad manner’ in current Scala community recently. New dispatch no longer need custom symbolic operator in many cases. See: https://dispatchhttp.org/Dispatch.html

    5. Kotlin is also more powerful than Java

    Many features in Kotlin are not just syntactic sugars:

    * declaration-site variance
    * unified type hierarchy
    * smart-cast (known as flow-sensitive typing)
    * function type with receivers
    * ‘native’ function type support

    These features cannot be implemented as syntactic sugars

    6. Kotlin and Scala both were designed to solve pragmatic problems

    Scala creator Martin Odersky said in the interview http://www.artima.com/scalazine/articles/origins_of_scala.html:

    > We wanted to create something that would be at the same time practical and useful
    > and more advanced than what we could achieve with Java.

    It means that Scala was also designed to solve pragmatic problems.

    As a conclusion, your article basically doesn’t rely on fact but your impression.

    Reply
    • Gabriele Tomassetti
      Gabriele Tomassetti says:

      Some of these observations are truthful, at least in part, but even then I don’t think they invalidate all the comparison itself, which is about 3000 words in length and generally correct. We did not create the article out of thin air: we talked with Scala and Kotlin developers, we read their opinions online and we look at the official documentation.

      1) Scala is obviously compatible with Java to some degree, but only when it does not impede its main objective of being a great standalone language. For example, you mention that it is compatible with Java lambdas, but that is more a merit of Java, rather than Scala. Java became closer to Scala, by implementing lambdas.

      Nobody is saying that is impossible to work with Java and Scala. Scala is compatible with Java, but it is harder to develop a software with full interoperability between the two. That is also because Scala is much more powerful than Java, and so if you want to use all its functionalities you cannot easily access them from Java.

      I realize that this is in part a matter of perspective, but this is a perspective shared by many others, for example the developers of Corda share the same idea.

      Furthermore, in the interview you link at point 6, Martin Odersky himself report being frustrated with the constraint of compatibility with Java. It also says:
      “I wanted to start with a clean sheet, and see whether I could design something that’s better than Java. But at the same time I knew that I couldn’t start from scratch”.

      For Scala developers Java compatibility it is simply a necessary hurdle. There is nothing necessarily wrong with that, all developers feel the pain of backward compatibility. However for some people it is a drawback.

      2-3) That is currently true. When we wrote the article Eclipse was the suggested IDE and the new documentation was in progress. We are going to update the article to reflect this.

      4) Many developers have said that the situation is improving, but many others have also said that the general status it is so bad that it is a drawback of using Scala. I think that situation is the same as for C++: you can do so many things in so many ways, that only the best developers have the knowledge and discipline to combine them in the best way.

      5) That is technically correct and we talk about several powerful features of Kotlin. However we were trying to convey the idea that Kotlin is designed to make a language that is better than Java, but still looks like Java.

      6) This is another matter of perspective. Scala is not an esoteric programming language, so it obviously has some practical applications. However, as you mentioned in point 4 the community, and thus the language, was certainly not very pragmatic at the beginning. That does not even take in account that the language was designed at a university.
      Pragmatism is a complex characteristic: other than the language syntax there is the whole ecosystem to consider. For instance, there was no good IDE, it was created by another company. There are also issues of compatibility with different environments. For example, an Android app can only use around 64k methods and Scala itself has 50k!

      We are not bad mouthing Scala or saying it is a bad language. We are just trying to present what Kotlin and Scala are good for.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *