Slides and Video: Kotlin@JVMLS 2011

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

About Andrey Breslav

Andrey is the lead language designer working on Project Kotlin at JetBrains. He also works on making the Java language better, serving as a Java Community Process expert in a group for JSR-335 ("Project Lambda"), and occasionally speak at software conferences such as Devoxx or JavaOne.
This entry was posted in General and tagged . Bookmark the permalink.

13 Responses to Slides and Video: Kotlin@JVMLS 2011

  1. Otto Christian says:

    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?

    • 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. matt says:

    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.

    • Matt,

      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.

  3. Olivier Gourment says:

    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?

    Thanks,

    Olivier

    • 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. Renoir says:

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

  5. Peter says:

    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.

    • 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. Greg Z says:

    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?

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

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 class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">