The Road Ahead

As you all know, we rolled out our first public release last week: And while you (7K+ unique visitors) are having fun with it, we keep working on the Kotlin compiler, IDE and standard library. In this post, I’ll give an overview of our plans.

What you can play with today

Today you can already try many features of Kotlin. Among others, these include:

  • Function literals (closures)
  • Extension functions and properties
  • Traits (code in interfaces)
  • Declaration site/Use site variance
  • First-class delegation
  • Compilation of mixed Java/Kotlin code

See Kotlin Documentation for more details.

Using things for real problems reveals limitations, inconsistencies and other downsides of the design, and this is good, because then we can fix them. The point is to find and fix virtually everything there is before we release the 1.0 version. After the release, we won’t be able to introduce backwards incompatible changes, so fixing the language will be difficult. So, please, go try them, and give us your feedback in the comments below or in the issue tracker.

What’s keeping us busy

Currently we are stabilizing the existing features and work on the IDE and language infrastructure (building etc). The hottest topics of this month are:

  • Modules: module = unit of compilation and dependency management;
  • Ant and Maven integrations: use your favorite build infrastructure;
  • Standard Library: utility functions for JDK collections, IO etc;
  • JavaScript back-end: still very early prototype, but it’s improving.


When playing with Kotlin it’s handy to know what’s not supported yet. The list is long, and some of these features may even wait for 2.0:

  • Visibility checks: it’s a pity we don’t have those private, public etc. yet;
  • Local functions: a function inside a function can be a very handy thing to have;
  • Labeled tuples (aka records): to return many things from a function;
  • KotlinDoc: like JavaDoc, but Markdown-based;
  • Annotations: customizable metadata to enable compiler extensions;
  • Secondary constructors: sometimes you need more than one;
  • Enum classes (Algebraic data types): like Java enums, but better;
  • Pattern matching: handy conditions over object structures;
  • Inline functions: zero-overhead closures for custom control structures;
  • Labels: break and continue for outer loops;
  • Type aliases: to shorten long generics etc;
  • Self-types: never write awkward recursive generics any more;
  • Dynamic type: interoperability wi JavaScript and other dynamic languages;
  • Eclipse plugin: Kotlin IDE != IntelliJ IDEA;
  • LLVM back-end: compile Kotlin to native code…

Even without this stuff, you can have a lot of fun. Try out extension functions and closures, traits and string templates and much more. Solve the problems (we wil be adding more over time).

Have a nice Kotlin!

About Andrey Breslav

Andrey is the lead language designer of Kotlin at JetBrains.
This entry was posted in Uncategorized. Bookmark the permalink.

45 Responses to The Road Ahead

  1. pron says:

    Great work so far, and I have high hopes for Kotlin.
    However, it seems to me that you’re trying to do too much, too fast. E.g. the last two items on the to-do list, dynamic types and an LLVM backend can surely wait. While we’re at it, the JavaScript backend can wait as well. Why not release a solid first version (with most of the items on the to-do list, as some of them are quite necessary, like KotlinDoc, annotations, visibility checks, secondary constructors, enums, pattern matching and more) for one platform – the JVM – and wait with the other platforms (JavaScript, native, whatever) for later, after you’ve built some following?

    Even for marketing reasons, it’s best to have one user community first and only then expend effort to reach others. It’s better to concentrate your efforts to gain a strong foothold first

    • Thanks for your care :)

      About the last items on the list: they are last on the list, and this is not arbitrary. One thing we disagree upon is JS back-end. We believe that it’s important to have two back-end on the early stage: helps us design the compiler and other parts of the project in the right way.

  2. Ian Clarke says:

    Isn’t a labelled tuple basically a class with only fields and no methods? What would the advantage be of labelled tuples over classes?

    • Hi Ian,

      The major advantage there is that there’s no new class created, i.e. no PermGen pressure and no cross-CL issues. + The syntax is consice, of course.

      • Ian Clarke says:

        Thanks for the reply Andrey.

        I understand the efficiency issue, however I worry a little that they are conceptually very close to classes, and so you would now have two very similar concepts, classes and labelled tuples, for programmers to choose between. It seems that a well designed programming language should avoid this kind of overlap.

        Regarding the syntax, could the syntax for defining a new class be generalized so that it is as concise as the planned syntax for defining a new labelled tuple?

        • I don’t think it is worth it to make class declarations so different from the traditional form. The primary point in tuples is avoiding creation of classes like Pair and Trinity, and labeled tuples just make this easier.

          One other thing is that tuples seem to be very important for pattern matching, and I see no reasonable way of replacing them with classes in this use case.

          • Cristian Vasile Mocanu says:

            It seems to me tuples (or classes like Pair or Trinity) is just a code smell.
            You lose the name. I don’t know about you, but “Point” says a lot more to me than “Pair”…

            In my opinion an ideal language would be even more restrictive than Java, not more permissive:
            - everything is private by default
            - everything is final by default
            - no primitive types
            - no public fields
            - etc.

            In addition, an ideal language would fix Java problems:
            - add runtime generics info (at instance level, not only at class level)
            - nicer visibility options – e.g. module visibility so we can have classes in different packages and still not be public (something like OSGi or the Java super-modules JSR proposal).
            - etc.

            Unfortunately, Kotlin is going the way of all the other languages. For example, supporting first class functions will only lead to unreadable code, because you can’t give a name to an anonymous piece of code (well, technically you can assign it to a variable, but people won’t).
            What Java lacks is a more concise syntax for anonymous classes, not full-blown closures.

            • Fortunately, Kotlin addresses many of your requirements:
              - everything is final by default

              - no primitive types

              - no public fields

              - nicer visibility options – e.g. module visibility so we can have classes in different packages and still not be public (something like OSGi or the Java super-modules JSR proposal).

              I have a couple of questions:

              - add runtime generics info (at instance level, not only at class level)

              What problems does this solve?

              Unfortunately, Kotlin is going the way of all the other languages. For example, supporting first class functions will only lead to unreadable code, because you can’t give a name to an anonymous piece of code (well, technically you can assign it to a variable, but people won’t).
              What Java lacks is a more concise syntax for anonymous classes, not full-blown closures.

              This seems a little controversial to me. You say “anonymous functions are bad, because they are anonymous”, and then “we need better anonymous classes”. What am I missing?

  3. Toland says:

    Is the demo currently the exclusive means to try out Kotlin? As a UX developer recently disappointed by developments in Flex I’m glad to hear JS is a priority. The front end sorely needs a Scala-like language and Fantom doesn’t quite quench it (Dart doesn’t even aspire). Could you provide more detail about the status of the JS back end? I suspect this community would be forgiving of fluctuating APIs given how fast our toolchains evolve.

    PS: Amazing work! You guys never fail to impress :)

    • The JS back-end is currently a very early prototype. We are working on making it better. The current priorities include making some practical examples work, this implies supporting some basic standard APIs.

  4. MuppetGate says:

    Looking at the first example in the web demo, I take it we’re going to have to use safe referencing for a lot of the stuff in the standard Java libraries.

    • We are working on this. First of all, nobody has to say “System.out?.println()” in Kotlin anymore, it just hasn’t made it to the Web Demo yet. + We will be smarter about many things that are actually non-null in Java.

      • MuppetGate says:

        Good news then … :-)

        I’ll keep an eye out for the changes.

      • Willis Blackburn says:

        This could be achieved by manipulating the strategy for resolving extension functions and member functions. If extension functions have priority, then if we wanted to indicate that Object.getClass always returns a non-null Class, we could just define a getClass extension function that calls Object.getClass and casts away the nullability. If that function was also inline, then the optimizer would probably just throw it away. Of course there would need to be a syntax for specifically targeting the object method instead of the extension function.

        • Extension functions should not have priority over members, because this may lead to very unpleasant bugs when someone adds an extension function to the package foo I import as “foo.*”, and I suddenly start calling wrong code. (See the comment below for the outline of our solution).

          • Willis Blackburn says:

            It’s always possible for someone to add something to a package or class that breaks existing code. If Kotlin prefers class members to extension functions, then someone could add a new member to a class with the same name as one of my extension functions, and that would also lead to errors. So the question is really whether extension functions should be considered as overrides or as fall-backs. The equivalent Scala feature works as a fall-back (Scala won’t look for implicit conversions if the method exists in the class) so maybe that’s the best model.

          • I don’t agree here: only the owner of the class can add something to it whereas anyone can add an extension method.

      • Peter says:

        Do you have a internal list of Java methods which cannot return null or does the compiler actually look into the called Java/Bytecode?

        If I want to call my own Java code, can I add annotations to the Java code which tell the compiler that a certain function never returns null?

        • Currently we simply keep correct signatures for the most popular Java methods. This is a temporary stub solution. We’ll switch to a system for externally annotating arbitrary code, so that you’ll be able to annotate your favorite libraries. + We will probably do a lot of the annotation work automatically for you (see the “Infer nullity” action in IntelliJ IDEA).

  5. starter says:

    KotlinDoc (with markdown) looks good.

  6. Noble Paul says:

    I’m impressed by the language and have been following it ever since it was announced. When can I get to see a kotlin compiler? I don’t see it in the list.

    Personally , I see the priority as

    1) A standard library
    2) compiler
    3) maven , ant tools

    and the language features can just keep coming

  7. Noble Paul says:

    Does Kotlin have normal fields (w/o getter or setter ) which are not properties? I could not find an example. I believe there is an over emphasis on the properties thing. The convoluted syntax for getter/setter looks like an overkill . It’s true that the EE guys use a lot of getters/setters but not everyone use them

    Is there a way to see the generated java code ? It may help users solve bugs /perf issues if something goes wrong

    • Kotlin does not allow public or protected fields w/o accessors. This is a common convention that everyone follows, and there is a rather good reason for it: binary compatibility. If all you need is something that works like a field, there’s no need in the “convoluted” getter/setter syntax, you can simply say:

      class A() {
      var a : Int = 0

      And get the same behavior but in a binary-compatible way.

      Regarding the binary code: thanks for your suggestion, we’ll add it to our WebDemo ToDo.

      • Stephen Colebourne says:

        Why are you assigning zero to an Int? Oh, you’re not, you’re assigning it to “a”. But thats what it reads like…

        • Aivar says:

          If you write

          Int a

          then somebody may ask “why are you applying ‘Int’ to ‘a’, is ‘Int’ a function?”.

          But I’d like to ask Andrey, why are you using

          a : Int

          instead of

          a: Int


  8. Noble Paul says:

    If all I need is a private mutable field (no accessors) is it possible? don’t you think the getters/setters add to the compiled binary size?

  9. Guangyu says:

    Thanks for creating such a great language.

    How do you consider concurrency programming? Is there a difference with concurrency programming in scala(see

    Do we need “synchronized” and “thread” keywords still ?

    • Whether you need “synchronized” sections or not depends on the kind of concurrency you would like to have. You surely can use it in Kotlin, but you don’t have to. Also, you can use Akka in Kotlin, as well as any Java library.

      Whether we are going to provide some library that would be unique to Kotlin is subject to discussion.

      On top of this, we are planning to support immutable classes, so that you can guarantee thread-safety of your data.

      • jlist says:

        Has anyone tried Akka with Kotlin? I actually tried to port a simple Java code to Kotlin. This is the code snippet:
        val system = ActorSystem.create(“mysysname”)
        system?.actorOf(Props(object: UntypedActorFactory {
        override fun create(): UntypedActor = HelloActor()

        It fails at run time with this error, which I don’t quite understand:

        Exception in thread “main” java.lang.ClassCastException: cannot be cast to

        I tried posting on Kotlin’s forum but unfortunately the 3 Kotlin forums are all read only even after I login :-(

        • This error should be fixed now, please take a fresh nightly build from here:
          (Don’t forget to uninstall the plugin before installing the new one). If it does not fix the error, please tell me.

          Regarding the forums, do you mean those at

          • jlist says:

            Thanks Andrey for the reply, and Kotlin team for fixing it. I updated the plugin. The code went pass the original problem but ran into another issue that appears to have something to do with akka failing to create actors. Since the Java version works, I’m not sure if it’s a kotlin problem or if it’s a problem with porting to kotlin. If you are interested please send me an email and I can send you the Java and Kotlin source code.

            Yes, that’s the forum link. I go to new, discussion, browse for a location, search for kotlin and see 3 items, all three are grayed out, not clickable.

            BTW, is there a way to send update emails if the comment gets a reply? I’m glad I checked back otherwise I wouldn’t know there was a reply to my comment :)

          • jlist says:

            Below is the error:

            [ERROR] [02/19/2012 00:50:07.891] [] [akka://mysysname/user/$a] error while creating actor
            java.lang.AbstractMethodError: namespace$2.create()Ljava/lang/Object;
            at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:195)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
            at java.util.concurrent.ThreadPoolExecutor$

          • Hi, as I don’t have your email address, could you attach the source to an issue in our tracker: ?

          • jlist says:

            I thought you could see the email I used when I posted the comments. Anyway, I just filed KT-1345 with the link to Scala code, Java and Kotlin source code in description. Thanks

  10. badlogic says:

    Exciting times ahead for Kotlin. Personally, i’m most interested in the JS-backend and the prospect of an LLVM backend. On the later: are there any concrete plans on how to go about this yet? E.g. will you guys try to leverage LLVM vmkit That could be a big win.

    Also, given Kotling has a JS and LLVM backend, that would open up a lot more oportunities for it to shine. Cross-platform game development could be one area.

Comments are closed.