Slides and Video: Kotlin@JVMLS 2011

Our slides and video from the JVM Language Summit 2011 is available via Dr. Dobb’s. Enjoy.

Comments below can no longer be edited.

13 Responses to Slides and Video: Kotlin@JVMLS 2011

  1. Avatar

    Otto Christian says:

    September 10, 2011

    Hello Andrey, and thanks. Really looking forward to using Kotlin!

    I got that the first public release of Kotlin will be sometime in Q4 of 2011 (which I guess could be soon). Is there anything earlier that one can perhaps sign up for, if I just want try the language and play with it?

    • Avatar

      Andrey Breslav says:

      September 11, 2011

      Hi Otto,

      Thanks for your interest in Kotlin. It is not a true release that is planned for the end of the year. It is a beta, which, among other things, means that the language design may (and most probably will) be changing incompatibly until a true release. So the beta is mostly intended for people who want to try the language, play with it and maybe give us some feedback.
      It may be that we’ll open something to a limited group of users before the beta, but for now it’s a little bit too early.

  2. Avatar

    matt says:

    September 26, 2011

    Hi Andrey, very nice.
    I’m wondering why Kotlin has variable declarations written with the type after the name, rather than before.
    I.e., Kotlin has:
    n: Int;
    rather than the more familiar (at least to Java, C++ and C# programmers):
    Int n;
    Was this just a “it’s look better” decision, or is there some more fundamental reason? (Maybe does it help the IDE somehow? Or is it more consistent somehow in more complicated declarations?)
    I wonder about this because (particularly in argument lists of function declarations) it seems like there will be a lot of colons, which might be visually distracting.

    • Avatar

      Andrey Breslav says:

      September 26, 2011


      Thanks for your comment.

      There are two main reasons:
      First, in our opinion it does look better and more consistent across different language concepts.
      Second, in this notation it appears to be more convenient and natural to omit types when they are inferred.

      On the matter of many colons: Pascal/Delphi, ML and Scala went this way, and colons are not a problem there.

      • Avatar

        matt says:

        September 26, 2011

        Thanks Andrey. I can’t wait to actually try it out.

  3. Avatar

    Olivier Gourment says:

    October 12, 2011

    Thank you for the presentation. I’m not sure I understand the concept of inlining functions… Is this only for speed optimization?

    When I modify an inline function, does the compiler detect it needs to recompile classes that use that function? Does it keep a signature somewhere? Or maybe I don’t understand what inline actually does?



    • Avatar

      Andrey Breslav says:

      October 13, 2011

      Hi Olivier,

      Thanks for your interest.

      Inline functions are for two things:
      * Performance optimization (speed and memory) gained from not creating objects for function literals passed as parameters to inline functions.
      * You can create new custom control structures, i.e. a loop that support break, continue and return properly.

      Of course, if an inline function is changed, all the call sites should be recompiled. A signature of an inline function is kept in the class file along with its body.

  4. Avatar

    Renoir says:

    October 14, 2011

    Which will be the platforms supported by the compiler? Will you target only Linux or also Windows?
    Thk you and congrats for your efforts.

    • Avatar

      Andrey Breslav says:

      October 15, 2011

      Kotlin is compiled to JVM byte codes, i.e. it runs everywhere where Java runs.

  5. Avatar

    Peter says:

    January 15, 2012

    From the video I understood that explicit returns are required in ‘normal’, non Unit type functions but obviously the function literals did not require them. This seems inconsistent to me. Not having to use explicit returns makes all code more concise, not just function literals. Also, I think it’d bother me to have to remember when I need an explicit return and when I didn’t.

    Otherwise I think the language looks great.

    • Avatar

      Andrey Breslav says:

      January 15, 2012

      This is subject to discussion.
      Functional literals obviously require short form like {x -> x + 1}.
      Named functions (not literals) tend to be long, and returning the last expression there appears to be not very readable.
      Allowing explicit returns in function literals leads to confusion in cases like:

      collection.foreach {
      if (it == 0) return // Intended to return from the outer function

      So we decided to say that named functions only have “return” operator and function literals only have the last expression returned.

  6. Avatar

    Greg Z says:

    June 10, 2012

    The beta version on Kotlin is still not released, isn’t it? You were planning to release it by the end of 2011. Did I skip something while searching or is it true?

    • Avatar

      Andrey Breslav says:

      June 11, 2012

      Since then, we revised the meaning of “Beta”. What we planned to release in late 2011 was actually released in early 2012 and was called a “public preview”, now we are releasing milestones one-by-one, and when the compiler is stable enough, we’ll call that a beta. We’ll release 1.0 after the beta is extensively used in production at JetBrains. Sorry for this confusion.

Discover more