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.

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.

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.

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.

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.

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!

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”.

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”

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

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.

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.

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.

Frankly, it smacks of a vanity project. We already have a pick of mature, highly expressive languages on the JVM and yours, to be blunt, looks like a grab-bag of features that were exciting ten years ago.

Scala is already much better than this looks like it could become in a foreseeable future, and if compilation speed was such a massive problem for you, well, how about doing something about THAT, rather than invent Yet Another Inconsequential Language?

I hope you’ll have the common decency to not shove plugins for this down our throats, at least with the paid version of Idea.