Why JetBrains needs Kotlin

The question of motivation is one of the first asked when someone learns that someone else is working on a new programming language. Kotlin documentation offers a fairly detailed overview of why the language exists. Still, we would like to make it clearer what exactly JetBrains expects to gain from the whole endeavor. We’re obviously in it for the long run, and yes, we realize it will take years to reach our goals. And here’s why we are willing to make this investment.

First and foremost, it’s about our own productivity. Although we’ve developed support for several JVM-targeted programming languages, we are still writing all of our IntelliJ-based IDEs almost entirely in Java. The IntelliJ build system is based on Groovy and Gant, some Groovy is also used for tests, there is some JRuby code in RubyMine, and that’s it. We want to become more productive by switching to a more expressive language. At the same time, we cannot accept compromises in terms of either Java interoperability (the new language is going to be introduced gradually, and needs to interoperate smoothly with the existing code base) or compilation speed (our code base takes long enough to compile with javac, and we cannot afford making it any slower).

The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.

The final point is less obvious but still important: new programming languages is a topic that many people really enjoy talking about, and the first days that have passed since we’ve unveiled Kotlin prove that. We see that people who are already familiar with JetBrains trust the company to be able to do a good job with this project. Thus, we believe that this trust and the increasing community awareness of JetBrains will not only drive the company’s business, but will attract even more people to our approach to building development tools, and let them Develop with Pleasure.

And we’d like to reiterate that our work on Kotlin does not in any way affect our investment into other development tools, and in particular the Scala plugin. If you’re already happy with Scala and have no need for another new language, we’ll continue to do our best providing you with first-class Scala development tooling.

This entry was posted in General. Bookmark the permalink.

29 Responses to Why JetBrains needs Kotlin

  1. florin says:

    Pretty honest. My exact thoughts as to why you guys did it. Looking forward to it.

  2. Cedric Gatay says:

    It is a really good thing to explain why and where you will use this new language.
    Let’s see how things go now…

  3. Erik Pragt says:

    Good luck with the development of Kotlin. I know the quality of the JetBrains team, and I know you’ve got the brains to make this a great language. I hope you can convince the community to invest in it, and learn to use this language next to other great languages like Scala and Groovy.

  4. Finally someone starts talking about compilation speed on the JVM. I must agree this is a very important point but oft forgotten. I remember compilation speed was touted a big feature when Go launched and everyone asked why. Now, over a year later everyone takes that speed for granted in Go.

    Compilation performance is also quite noticeable in Scala. The Scala compiler isn’t exactly a performance monster, in fact it can be quite painful to use.
    Doing web dev with Java can actually produce instant edit-save-reload turnarounds with the Play Framework. However trying to do the same with the Scala version of that same framework yields turnarounds of ~5 sec.

  5. tintin says:

    Why not Scala? It has cool FP cookies, strong typing, yet good performance.
    Huh?

  6. Germán says:

    so, there won’t be a Kotlin eclipse plugin?

    • I’ve added a FAQ answer on this topic. It says:

      We plan to provide two things:
      1) An open source Eclipse plugin that will be initially contributed by JetBrains, and later we will gradually move it’s support onto the community.
      2) API exposed by the compiler, to make it easy to retrieve semantic information from within the plugin.

      In any case, Eclipse support will be released later that IntelliJ support.

  7. Pingback: Twitted by jbaruch

  8. steve says:

    Just wondering … what happens when Eclipse ships with a Kotlin plugin which also does JEE? What’s the selling point for Kotlin’s EE support in IDEA?

    Although I wonder if any Eclipse/Netbeans people step up to write a Kotlin plugin, to help a completely different vendor to sell his IDE …

  9. Dmitry Jemerov says:

    Steve,
    This would be no different from the current situation, when Eclipse ships with a Java plugin which also does JEE, except for the fact that we don’t expect the Eclipse Kotlin plugin (developed by either JetBrains or the community) to be as full-featured as the IntelliJ plugin.

  10. steve says:

    Are there plans to make the language simpler and use less esoteric operators? Things like http://confluence.jetbrains.net/display/Kotlin/Nonlocal+returns+and+jumps are just unbelievable bizarre.

  11. Great post, appreciate the directness. I am glad you appreciate the trust your community has in JetBrains, doubly glad you made the point explicitly.

    I’ve been looking for “the next great thing” in languages for many years now. After JDK6 I believed SUN would let Java go the way of COBOL and stagnate, and current pronouncements from Oracle only reinforce my belief. The redeeming fact was an ever improving JVM.

    Kotlin scratches the right spots for me, and leverages the JVM as much as possible. Thanks!

  12. Anderson says:

    The name Kotlin does not sound too good. It sounds more Russian than English. Is this the final name for the language ? Hope that the name can be amended to sound more marketable and “comfortable” in simple English term. For your info, the name “Kotlin” in Chinese dialect Hokkien (http://en.wikipedia.org/wiki/Hokkien ) means “Pitiful”.

    — eg :DD
    Scalin, Intellin, Jelin,

  13. Arik Kfir says:

    Congratulation and best of luck – as someone said in an earlier comment, Kotlin seems to “scratch the right spot” and I hope it will provide the right balance between features and ease of development. Remember Josh Bloch said once that one of the things that did the trick for Java’s success was not “what they [Sun] put IN Java, but what they left OUT of Java” :)

  14. Xavier says:

    Hello!
    Will you use MPS to create Kotlin?

    Regards

    • Dmitry Jemerov says:

      No, we are not using MPS to create Kotlin. Kotlin is an ordinary text-based language, with a grammar and a compiler that generates JVM bytecode directly.

  15. opensas says:

    Great initiave, I wish you all the luck

    BTW, I’d like to know why you dicarded scala… is it because of compile times? or was it too different from java? And what’s your opinion on fantom, gosu, ceylon, etc…

  16. florin says:

    I’d call the language: intellij.

    I had to repeat the name kotlin several times to make sure it sticks. Besides, it appears it has bad connotations in serveral languages. The jokes will never end – bad for addoption.

  17. Jonathan Locke says:

    There’s always room for another language. I like some of the things you’ve left out as I can’t see using Scala at work with all the sharp edges it has. A more English syntax (as opposed to Scala which looks very mathematical) is also appreciated, although I do wish there weren’t abbreviations… can’t we say, for example, “function” instead of “fun”, “func”, “def” or “defun”? The IDE is going to complete these abbreviations anyway and they’re just not intuitive to look at. I do hope that you will include something like the Scala package scoping syntax. That’s a major improvement for library writers like myself. I’m glad to see traits, although I wish someone would sit down and figure out how to make generics intuitive. They’re terrible (although very useful!) in Java. Can’t wait to see how it shapes up. — Jon

    • Jonathan,

      Thanks for your comment.

      As you’ve mentioned “Scala package scoping syntax”, I wonder if you mean visibilities like “private[foo.bar]” or the syntax for “opening package scopes”?

  18. Jonathan Locke says:

    By the way, I couldn’t care less about compilation speed. Not one bit.

  19. Buster says:

    I agree than an English like syntax is preferable to saving the programmer a few keystrokes with crazy symbols like Ruby and some other languages do. i++ always makes me go WTF? Why not just say i=i+1? Anyone can understand that.

    loop: for (i in 1..100) {
    for (j in 1..100) {
    if (…)
    break loop
    }
    }

    is preferable to the @ syntax in my opinion.

    • Buster says:

      Also, I sure hope Kotlin plays well with Android. Java is a pain in the neck to try and get an app up and running quickly. SL4A just doesn’t cut it. Kotlin seems like a perfect choice for Android app development and would speed acceptace of Kotlin as a real competitor to the other JVM languages.

    • Unfortunately the “label:” syntax interferes with type annotation, but we are looking for some alternatives to the “@label” notation

  20. Robert says:

    Sounds interesting. Will the language also provide some direct support for concurrency and parallelizm (Actors), which is a primary goal for Scala ? This will be a very important part for the future using multicore systems.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>