The Road Ahead

Posted on by Andrey Breslav

As you all know, we rolled out our first public release last week: kotlin-demo.jetbrains.com. 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.

ToDo

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!

Comments below can no longer be edited.

45 Responses to The Road Ahead

  1. pron says:

    January 16, 2012

    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

    • Andrey Breslav says:

      January 16, 2012

      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:

    January 16, 2012

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

    • Andrey Breslav says:

      January 16, 2012

      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:

        January 16, 2012

        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?

        • Andrey Breslav says:

          January 16, 2012

          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:

            February 15, 2012

            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.

            • Andrey Breslav says:

              February 16, 2012

              Fortunately, Kotlin addresses many of your requirements:
              – everything is final by default
              Yes!

              – no primitive types
              Yes!

              – no public fields
              Yes!

              – 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).
              Yes!

              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:

    January 16, 2012

    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 🙂

    • Andrey Breslav says:

      January 16, 2012

      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:

    January 16, 2012

    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.

    • Andrey Breslav says:

      January 16, 2012

      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:

        January 16, 2012

        Good news then … 🙂

        I’ll keep an eye out for the changes.

      • Willis Blackburn says:

        January 17, 2012

        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.

        • Andrey Breslav says:

          January 17, 2012

          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:

            January 18, 2012

            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.

          • Andrey Breslav says:

            January 19, 2012

            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:

        January 17, 2012

        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?

        • Andrey Breslav says:

          January 17, 2012

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

          • Aivar says:

            January 20, 2012

            Are you going to use external annotation format from here http://types.cs.washington.edu/annotation-file-utilities/ or you develop a new notation?

            (I’m currently searching for good notation myself)

            • Andrey Breslav says:

              January 20, 2012

              The JSR-308 annotation format is not too bad. We haven’t decided on the format yet, but it would make sense to have it aligned with Java’s

  5. starter says:

    January 19, 2012

    KotlinDoc (with markdown) looks good.

  6. Noble Paul says:

    January 19, 2012

    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

    • Andrey Breslav says:

      January 19, 2012

      Thanks for your interest in Kotlin!
      The compiler exists already, of course. It compiles your programs here. We are stabilizing it now so that you get a smoother experience when it’s published.

      • Paul says:

        February 10, 2012

        Any news about release date?

        • Andrey Breslav says:

          February 10, 2012

          We will open the compiler/IDE pretty soon.

  7. Noble Paul says:

    January 19, 2012

    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

    • Andrey Breslav says:

      January 19, 2012

      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:

        January 19, 2012

        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:

          January 20, 2012

          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

          ?

          • Andrey Breslav says:

            January 20, 2012

            Good question. The answer is “bad habit from Pascal”… We should probably reconsider this

          • Chris Kent says:

            January 24, 2012

            I agree, I find function definitions easier to read with the Scala style a: Int than the Pascal style a : Int

  8. Noble Paul says:

    January 20, 2012

    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?

    • Andrey Breslav says:

      January 20, 2012

      If you declare a private property, no accessors will be generated, because there are no binary compatibility issues in this case.

  9. Guangyu says:

    February 1, 2012

    Thanks for creating such a great language.

    How do you consider concurrency programming? Is there a difference with concurrency programming in scala(see http://www.ibm.com/developerworks/java/library/j-scala02049/index.html)

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

    • Andrey Breslav says:

      February 1, 2012

      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:

        February 18, 2012

        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()
        }))?.tell(“start”)

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

        Exception in thread “main” java.lang.ClassCastException: akka.actor.ActorSystemImpl cannot be cast to akka.actor.UntypedActorContext

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

        • Andrey Breslav says:

          February 18, 2012

          This error should be fixed now, please take a fresh nightly build from here: http://teamcity.jetbrains.com/viewLog.html?buildId=lastSuccessful&tab=artifacts&buildTypeId=bt345
          (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 http://devnet.jetbrains.com?

          • jlist says:

            February 19, 2012

            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 🙂

            • Andrey Breslav says:

              February 20, 2012

              The forum should be fixed now

          • jlist says:

            February 19, 2012

            Below is the error:

            [ERROR] [02/19/2012 00:50:07.891] [mysysname-akka.actor.default-dispatcher2] [akka://mysysname/user/$a] error while creating actor
            java.lang.AbstractMethodError: namespace$2.create()Ljava/lang/Object;
            at akka.actor.Props$$anonfun$$init$$1.apply(Props.scala:122)
            at akka.actor.Props$$anonfun$$init$$1.apply(Props.scala:122)
            at akka.actor.ActorCell.newActor(ActorCell.scala:343)
            at akka.actor.ActorCell.create$1(ActorCell.scala:360)
            at akka.actor.ActorCell.systemInvoke(ActorCell.scala:450)
            at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:195)
            at akka.dispatch.Mailbox.run(Mailbox.scala:164)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
            at java.lang.Thread.run(Thread.java:662)

          • Andrey Breslav says:

            February 19, 2012

            Hi, as I don’t have your email address, could you attach the source to an issue in our tracker: http://youtrack.jetbrains.com/issues/KT ?
            Thanks.

          • jlist says:

            February 19, 2012

            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:

    January 16, 2013

    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 http://vmkit.llvm.org/? 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.

    • Andrey Breslav says:

      January 16, 2013

      We are investigating a possibility of re-using clang to integrate with existing C/C++/Objective-C libraries, but this is very open-ended. We might use vmkit, too.