The documentation for Kotlin is now located on the new site. This page is kept for historical reasons

Skip to end of metadata
Go to start of metadata

The documentation for Kotlin is now located on the new site. This page is kept for historical reasons

Welcome to Kotlin documentation page. Please consult the menu on the left.

Some quick links:

  • No labels


  1. Anonymous

    It likes Groovy. What's difference?

    1. Anonymous

      It looks like groovy, while remaining strongly typed. Big difference!

      1. Anonymous

        Groovy is strongly typed. Perhaps you meant statically typed?

        1. Yes, I believe they did.

  2. Anonymous

    The kotlin code examples are not very readable in IE. They appear on one long line.

    1. Anonymous

      stop using IE 

    2. Anonymous

      Love the new feature.

    3. After spending a whole day implementing workarounds & quirks for IE6 (yes, there are still dinosaurs using IE6 in 2012!) I just want to peacefully shot people who are using IE — in any version.

  3. Anonymous

    Why, if there is Scala already, right with IntelliJ IDEA plugin for it?

  4. Anonymous

    There are a lot of computer languages in the world already, I think it would be better for IntelliJ to concentrate its efforts for the current products (IDEA for instance) because they have got still not ideal quality

  5. Anonymous

    It seems like Kotlin hasn't been designed with concurrency in mind. Do you guys have plans to address this issue in later revisions of the language?

    1. For now, Kotlin inherits Java's concurrency infrastructure, and we are planning on having an actor library, and maybe something like C#'s async-await in future versions.

      1. Anonymous

        C#'s async-await is loosly based on F# asynchronous workflow, which is far superior to C#'s async-await.

        In other words, if you're looking for inspiration, look at the way F# does it rather than C#.

      2. Anonymous

        What about support for STM on a language level?

        1. Not until one manages to implement that effectively over JVM

        2. Sounds pretty scary. Could you point me to some source that explains how this can be done efficiently on the JVM?

          1. Anonymous

            Clojure has STM support: http://clojure.org/refs

            1. Thanks.

              That's a library, not a language feature. You can use Closure STM inside Kotlin, if you like.

  6. Anonymous

    Why not "def" or "function", but "fun"? Don't you think it's a weird keyword name?

    1. We'd like people to have fun while programming (smile)

      1. Anonymous

        I'm afraid it's not fun anymore iif it's a keyword

      2. Anonymous

        With operator overloading it certainly becomes fun times (big grin)

        I'll get me coat...

      3. Anonymous

        +1 for "def"

    2. Anonymous

      I always that it is good to give my variables and properties descriptive names.

      Why would you use the shorthand fun?

    3. Anonymous

      Au contraire, I'm so glad that it's "fun" - finally someone did it right for a change. Using "def" for functions always sounded silly to me - it would make some sense if it was for all definitions (as "define" is in Scheme), but ever since Python misappropriated it for functions only, it has been spreading in that role all over the place like cancer. Meanwhile, if you use "var" to declare variables (which makes perfect sense!), then surely the obvious counterpart for functions is "fun"! ~

      1. Anonymous

        I don't think "fun" is a good keyword. "func" is better, "def" is the best.

        1. Anonymous

          "def" (short for "definition") is overly generic compared to "fun". I'm in favor of "fun" as a mnemonic (as opposed to spelling out "function") because (a) There is no real chance that a developer is going to misunderstand what "fun" is (as opposed to, say, naming your variables "str_cr_wrth", yet (b) fun is nice and compact where it counts. Less typing with clarity retained.

        2. Anonymous

          How about "fn" like Clojure?

    4. Anonymous

      +1 for fun.

    5. Anonymous

      `fun` is really strange. I like all the other features except this.

      +1 for `def`

    6. Anonymous

  7. Are there any plans to add support for immutable objects?  e.g. something like Scala's copy() method on case classes?

    1. Yes, we are considering something like this, but the decision on these things will be postponed a little as it falls more into the category of library development, and we are not exactly there yet.

  8. Anonymous

    Another language, really? Don't you guys have anything to do?

    1. Anonymous


      Why don't you continue to invest your resources in being the best tools / IDE maker on the planet?!  Seems like a waste.

      IntelliJ is still the best out there, but isn't nearly as snappy as 3, 4.5, or 5.x days :(

      Eclipse is certainly catching up and offers many things that were once core IntelliJ features like intentions and intelligent refactoring

      1. Drifting OT from Kotlin, but I find current IntelliJ as snappy as the old days.  I work with hugely larger codebases now, with much more tools integration (Spring, Maven, etc.) so I'm asking a lot more of my editor than I use to.

      2. Catching up, funny how they have been saying that for years.

  9. Anonymous

    You guys should help to improve Scala instead of creating a Java 2.0.

    1. Anonymous

      Scala is very overcomplicated already, and gets more and more so. No sane person should have to contemplate the semantics of things like path-dependent types, IMO. I don't think it stands a chance at becoming a mainstream language given these things.

      Kotlin, now - I can see this work. It takes the nice and _simple _stuff from Scala without overdoing the features, and the result is somewhat more extensive than C#, but not by so much as to make it overcomplicated. That, and - unlike Scala - I'd expect that release 1.0 of the language would have complete IDE support for all language structures - whereas with Scala, all plugins for all IDEs out there still struggle to get it right (which, by the way, does tell something about the complexity of the language... wonder if it takes as long for Scala as it did for C++ in the end).

      So, bring it on!

      1. You are saying that Scala has complicated features. That might be true, but you don't have to use them! If you think that path-dependent types are hard to use - just don't use them, use only the simple Scala features. I don't really see any reasons why Kotlin was invented.

        1. Anonymous

          Oleg, that is impossible in the real world. When you're coming to a project of legacy code (that hundreds different people written several yyears), you have no chanses ignore all scala overcomplicated features. You'll have to understand all of them.

          1. There are coding standards for that. At the build time post-processing parser can make sure that there are no advanced scala features used in the code and fail the  build if it finds some. By doing this you ensure that none of those hundreds of people have any chance of introducing scala complexity into the code.

            1. Anonymous

              Which, while a nice thought, leaves you with same problem as C++'s abundancy of features. Every team and project uses a different subset of Scala and you're back where you started.

          2. Anonymous

            Personally, I think that raising the entry standard for programming is a good thing. There are too many lazy incompetent programmers out there already without making it even easier for them.

    2. Anonymous

      Absolutely right.

  10. Anonymous

    This looks absolutely wicked - I'll be checking it out as soon as it hits the streets. Scala is overly complex and the features you've outlined here would make Kotlin a real contender for industrial use. Open source licensing is also a plus point - nice work guys. 

    1. Anonymous

      In which areas do you think Scala is more complex?

  11. Anonymous

    I've got a couple of questions regarding reification of generics:

    1) Do you compile Kotlin to plain old JVM bytecodes? 

    2) Does Kotlin reification achieve feature parity with .NET?

    3) Could you, please, describe the way you reify the generics? Do you attach a reified type to every single object or it's something else?

    1. 1) Yes, absolutely
      2) Depends on what you mean by feature parity. For example, .NET's JIT specializes generic classes upon instantiation, and Kotlin does not do that (at least, for now).
      3) For now, we attach a field with a TypeInfo object to every instance of a generic class. I'm not aware of any other reliable ways to reify the type information.

      1. Anonymous

        You can use name mangling, like in good old C++ so List<Int> becomes List__Int.class. We've used this loooong ago in 2002 in our toy JVM language.

        Scala also does this with @specialized annotation.

        1. Yes, there're other solutions, too. But for now we decided to refrain from implementing them.

          1. Anonymous

            I'd really like to take a stub at this problem once the compiler arrives.

  12. Anonymous

    I absoluteley _love_ Kotlin. It seems to be the JVM language of my dream. I've listed some things I love here: http://rsdn.ru/forum/philosophy/4349959.1.aspx

    A few questions though:

    1) Are tail calls optimized? If yes, then @tailrec annotation from Scala will be needed.

    2) Collections library. You should steal it from Scala, probably.

    3) Lists and pattern matching. It would be nice to be able to do something like:

    Also, is it possible to receive access to Kotlin compiler? I _really_ want to play with it.

    1. 1) They will be, and the annotation will be there
      2) There will be a collections library, and we will definitely look at Scala's one and consider other designes as well
      3) Something like this is possible, not with the infix ::, but still

      The compiler is a little bit too early stage to be played with, but we'll fix that soon (smile)

      1. Good grief, TCO!?  This is fantastic news.

  13. Anonymous

    Could I ask in what language are you developing compiler? Is there plan to have Kotlin Compiler in Kotlin itself?

    1. The Kotlin compiler is currently developed in Java. We'd like to rewrite it in Kotlin some day, but it's not a very high priority; it will definitely not happen before the beta release.

      1. Anonymous

        It sounds like Kotlin is mostly a superset of Java (excepting a few things such as raw types?). So it should be possible to do direct automatic code translation from Java to Kotlin eventually.

        1. We do plan to implement an automatic conversion tool, but obviously it will just provide a straightforward translation. To have code written in an idiomatic way, you have to write it in Kotlin, not convert it automatically.

  14. Anonymous

    Why not to get Kotlin free of curly braces?

    1. Anonymous

      Completely agreed. This should be an array language.

    2. Anonymous

      I think the biggest problem with your proposal is that it then wouldn't look almost exactly like scala.

  15. Anonymous

    1. Will there be a REPL?
    2. What's your preferred way of getting comments? On this wiki? On the blog? Is there a mailing list? 
    1. 1. Yes
      2. This wiki so far. Indeed, we're receiving somewhat more feedback that we expected and thinking of setting up forums and mailing lists. What platform would suit best, what do you think?

      1. Anonymous

        1. Cool! :)
        2. I don't know about forum/mailing list platforms. You already have Confluence, maybe you just need to set up a discussion page for each major topic.
      2. Wiki is best but does not scale, as you imply.  My mild preference is for Google groups: public record, reader can get mails if they choose, JetBrains can set up special interest subgroups as warranted.

  16. Anonymous

    cool story, bro

  17. Anonymous

    Nice. But why make the same syntactic mistake that Scala and Mira made (and Ceylon seems to avoid)?

    Example (in Java):

    Cust<enter Ctrl-Space>
    Customer firstTime<enter Ctr-Space> 
    Customer firstTimeCustomer; 
    Customer recurring<Ctr-Space> 
    Customer recurringCustomer; 

    How could you possibly do that when you have to type the name of the variable first?

    firstTimeCustomer : Customer


    -- Bob Lauer

    Warum sie aber den selben Quatsch wie Mira und Scala machen, den Variablennamen vor den Typ zu schreiben, habe ich noch nicht verstanden. Wie soll man da Code Completion einsetzen?
    z.B. in Java:
    Customer firstTime<Ctr-Space>
    Customer firstTimeCustomer;
    Customer recurringCustomer;

    1. With type inference you normally wouldn't have the type name at all.  So it would be

      val firstTimeCustomer = Customer(...)

      You can always use introduce variable and let IDEA create the variable for you:


      val <caret>customer = Customer(...)

      It works beautifully in Java and you don't even have to start typing the type name.

      1. Anonymous

        Well, it *works* in Java (Strg-W is your friend, or Shift-Alt-V in Eclipse), but it's not really what I would call beautiful.

        A *really* cool thing would be a language that does away with all the naming redundancy and allows you to define an onthology of names (some generic, some domain specific). For example: Why should you be allowed to write

        String number = "hello";

        Integer text = 2;

        That's syntactically valid Java code, but semantically it's complete nonsense. An onthology would clean up the naming mess, improve project communication, *and* require less typing (just dreaming, it'll come one day).

        So you'd write:

        isbn<purpose> is number;

        new, bought is purpose;


        isbnNew = "1234";

        isbnBought = "3498";

        (static typing, (almost) without the typing part!)

        -- Bob

  18. Anonymous

    Looks cool.  One thought. What about exploring the idea of adding fancier type checking.  For example if we have a method (in Java):

    void f(double x);

    We know that x must be a double, but if have to look at the documentation to see that it must be between [0,1] ... etc.  I don't know what would be appropriate syntax, but this is a whole new language, can try out new things!

    void f(double[0..1] x);

    1. Though not absolutely impossible, that's a little hard to do )

      1. Anonymous

        What about a syntax that is readable .. good documentation, but instead of static type checking, it would generate the appropriate asserts.  So ya, the fancier stuff would be a runtime error, but still you would have the documentation and also a nice layer to ensure proper ranges/values during development.

        1. I think, this might be doable in the form of a language extension.

          1. Anonymous

            How about Design by Contract support?  At least for pre-conditions and post-?

            1. We plan to have a language extension for this as well

    2. Anonymous

      Right now, I don't know of any usable/industrial-grade type system that would implement what you want (partial/restricted types) without resorting to heavy use of assertions.

      And if assertions are okay, it would seem best to me to take directly the route of including full Design by Contract.

  19. Anonymous

    Oh also possibly something for array restriction

    f(int[] x)   (how can we indicate that this array must have 8 values, or be a multiple of 8, etc

    Support for multidimensional arrays


    support for complex, long long, double double ... would be awesome to.

  20. Anonymous


    Could you please publish a PDF/ePub version of this guide as well?

    Thanks in advance,


    1. Currently it's difficult to have a publishable quality document out of this wiki. But if you like, I can send you HTML that's more or less OK, and you can convert it as you like. Drop me an email at andrey.breslav[]jetbrains.com

      1. It's not too difficult actually. You just need to create one-page version of documentation using "{include}" wiki syntax (see MPS User's Guide (one page) for example). And on that page you need to invoke Tools -> Export to PDF.

        1. I'll try this. Thanks!

  21. Anonymous

    Hello JetBrains-Team! (smile)

    At work I develop in C# with Visual Studio and ReSharper and at home in Java and Scala with IntelliJ IDEA. Each of these programming languages has great features, but none unfortunately contains all.

    It's not that long ago that I said: "There should be someone who takes the best things of the current programming languages (C #, Java, Vala, Scala, etc.) and creates a new language which contains all great features of them."

    And now I've come across Kotlin. The language is gigantic! It has everything one need – especially the long awaited null-safety.

    With this language you do not longer simply write sourcecode – with this language you compose a symphony!

    I can hardly wait for the public beta. (big grin)

    You are great! Keep it up!

    Best regards,

  22. Anonymous

    Whats the GUI library going to look like?

    1. No particular work have been done on this yet. One is supposed to code against existing APIs like Swing, SWT etc.

  23. Anonymous

    Kotlin looks really nice -- thank goodness someone is trying to create
    a humane compiled language for the JVM. I love that control structures
    are expressions and it's interesting to see the influence that dynamic
    languages are having on modern compiled languages.

    What I would love to see in Kotlin is some syntactic sugar:

    1. Regular expression literals and operators (Ruby) and "hereregexes"
       (CoffeeScript: http://jashkenas.github.com/coffee-script/#regexes).

    2. Single quoted string literals that don't do any interpolation or
       escaping (Ruby, CoffeeScript).

    3. Indentable Heredoc strings (CoffeeScript:

    4. Comprehensions (Python, CoffeeScript).

    Disclaimer: This stuff is off the top of my head, please excuse any
    gaffs -- dynamic languages are my thing (my language de jour is
    CoffeeScript). Would love to program for Android but can't face
    returning to Java and haven't got enough brain cells for Scala.

    Looking forward to the first public release.

    Cheers, Stuart
    Stuart Rackham

  24. Anonymous

    "Industrial Use."

    What does that mean specifically?

    1. Anonymous

      Not to put words in their mouths but as I understand it I think this comment from Hermann Schmidt on Infoq nails it:


      1. Anonymous

        Yes, that seems about right, and leads to a worthy set of design principles that I would sum up like this :

        1. Consolidation rather than innovation: following identified best practices; eliminating failed features; taking inspiration from the good parts of a variety of other languages.
        2. Making developers' life easier/more fun: reducing boilerplate code while staying close to the Java syntax; making hairy features understandable and usable; reducing easily avoidable mistakes; and maybe later improving of the dubious parts of the Java library.

        I commend them for such a lofty project, but I wish they'd take cues from another language that had "industrial use" as its main goal: Eiffel. (Even if it didn't make as big an impact as its creator Bertrand Meyer would have wished, its influence can be felt today-viz. properties-, and IMHO Design by Contract is an idea still waiting to make its big splash).

        Anyway, I cannot wait to see how it will finally turn out. Thanks, JetBrains!

  25. Anonymous

    Will Kotlin support Android right away? 

    1. AFAIK any language that compiles to JVM bytecodes does

      1. Anonymous

        Yes, that's true, but the thing needed is build support.  Right now if I want to build an Android app I have to either use Eclipse or Intellij which will build the APK, or I have to write an Ant build.  Either way, some build tool is needed.  For Scala there's an eclipse plugin: http://code.google.com/p/treeshaker/  

        1. I see what you mean. We will provide something like this, but probably not in the first public beta. I created an issue in our tracker: http://youtrack.jetbrains.net/issue/KT-296

  26. Anonymous

    What is JetBrains' primary motivation to start develop this? At first glance, this looks like a long-running, expensive project. What's the intended trade-off?

  27. Kotlin looks nice so far. Thank you for doing this.

    A few observations/requests...

    1. I would love to see a "Java 2.0" language (like Kotlin) implement 64-bit indexable arrays (and thus implicitly 64-bit size support for collections, etc). I know that this more a JVM limitation, but the JVM has lacked this feature mostly because its language (Java) can't implement this feature without breaking backwards-compatibility, so why bother supporting it in the JVM? However, if our goal is to migrate away from Java and move the JVM forward (by creating a new JVM language like Kotlin), I think it would be nice to bake in this feature from the start. Perhaps, as a segue, the Kotlin collections package could support 64-bit sizes, even though the underlying implementation would only support 32-bit sizes. Or perhaps the Kotlin collections package could use multiplexed 32-bit indexable arrays to implement 64-bit indexable arrays. In any case, with current server hardware, it is not uncommon to see 64GB-128GB of RAM on one machine. I have certainly run into situations (actually, quite often these days), where I would like to have more than ~2 billion elements in, say, a HashMap, but need to resort to either multiplexing tricks, or multiple JVMs (either on the same machine or distributed across a cluster of machines). The point is, the 32-bit array indexing limitation seems rather old-fashioned these days, and if it weren't for Java's legacy issues, I would have no doubt that the JVM would fix this. Perhaps Kotlin could help to push this feature into the JVM. See fastutil for an excellent, highly optimized (performance and space) primitive collections library, including library support for 64-bit indexable arrays/collections (albeit generally slower because of multiplexing).

    2. Another thing I would love to see is support for optimized collections when the parameterized types are primitives. I know that Kotlin abandons the notion of primitives as a language construct, however, nothing prevents the compiler from using optimized versions of the collections classes when the parameterized type is analogous to a Java primitive type. For example, nothing prevents a HashMap<Long, Boolean> from actually using something like a LongToBooleanHashMap behind the scenes. Again, see fastutil for an excellent, highly optimized (performance and space) primitive collections library. I know that there has been some work in Scala using @specialized and fastutil.

    3. I know this might be "opening a can of worms", but has there been any consideration for a language construct like C++ "const"? I would love it if we could have immutable objects without having to resort to class pairs like List/ImmutableList, etc. This isn't to be confused with Kotlin's/Scala's "val" and Java's "final", which only make references "immutable" (set-once).

    1. +1 for const.

      I really like Fantom's approach.  Immutability is baked into the type system and thread safety is enforced by only allowing immutable objects to be passed between threads.


      Also +1 for something like Scala's @specialized annotation.  Although maybe this isn't a feature for v1.0.

    2. 1 and 2 are mostly on the VM side. It's not impossible to do on a language level, but it's difficult and runtime penalty is high. 2 is easier than 1, though.

      3 is totally possible, and we currently plan it to be a custom annotation, and not a part of the language design

      1. Hi Andrey,

        So in reference to #1, so what if the Kotlin collections package used 64-bit sizes in the interfaces (but not in the implementations)? For example, instead of something like "List.size() : Int", we would have "List.size() : Long". The List implementation classes that Kotlin supplies may only support Int-sized lists, but at least someone else could implement a list that supports Long-sizes without having to create an entirely separate and incompatible interface (BigList, etc).

        Just a thought.

        1. I see your point. One other detail to think about here is why 64-bit and not 128 or 1024?

          1. I like the way you think :)

            I'm all for > 64-bit support for really future-proofing things. However, it's not so much that 64-bit support "future-proofs" anything, but rather "current-proofs"... the 32-bit limitation is very antiquated at this point.

            Being careful not to generate any "N is all you'll ever need" statements, but Long.MAX_VALUE is a huge improvement over Integer.MAX_VALUE, which, for example, is 8 exabytes versus only 2 gigabytes. And it's not even so much about "how many bytes", but rather "how many items" can be supported in one collection. In this aspect, Long.MAX_VALUE is huge improvement, and would allow for even distributed Collection implementations that span 100s/1000s of machines to be API-compatible with "regular" Collection implementations.

      2. Anonymous

        Since immutability is such an important issue, can you create an extra confluence page that elaborates on this?

        1. As soon as we get it fully thought through

          1. Anonymous

            Well, here are some issues that I think are important.

            1. Should immutable classes be stack-allocated as in C# (http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx)?
            2. Should immutable classes be automatically co-variant? This one is actually bugging me for a long time and I don't have a perfect solution yet.
            1. 1. To our knowledge, this is impossible to implement on the JVM in a reasonable way
              2. This is unsound. Variance does not have anything to do with mutability. Consider these immutable classes:

              open class Formatter<T> { 
                abstract fun format(t : T) : String 
              class IntFormater() : Formatter<Int> { 
                override fun format(x : Int) : String = x.asHex() 

              Can IntFormatter be assigned to something of type Formatter<Any>? No, because its implementation of format() will break if you pass anything but an Int there. And these classes don't even have state (either mutable or not).

  28. Anonymous

    What is JetBrains' primary motivation to start develop this? At first glance, this looks like a long-running, expensive project. What's the intended trade-off?

  29. New JVM languages (Clojure, Groovy, JRuby, Scala, etc., now including

    Kotlin) are probably the bright future of Java platform. Nevertheless, they are often
    rejected by major customer as "not reliable", "not enterprise" or "not yet mature".

    When starting to create Kotlin, don't you have a strategy how to face it?

    In my view, there are several categories of customers:

    1. Customers who request Java bytecode; they could get, in theory, Clojure / Groovy / etc. compiled into bytecode - this is the simplest situation
    2. Customers who request Java source code
    3. Customers who request Java source code and will maintain it by themself - here we can't probably find a way out

    For the 2nd category, a partial workaround might be to decompile Java bytecode and
    "masquerade" it a little. I mean, replace those parts that are most strikingly
    of other origin than Java.

    Let's take as example name of an inner class that serves to implement a closure.
    From AST of Clojure / Groovy / etc. source, we know e.g. the method that passes the
    closure as its parameter, the variable the closure might be assigned to etc.
    So the inner class name could be replaced automatically by something that could
    go more or less unnoticed. Generic terms such as "Handler" or "Processor"
    could be used as glue.

    It could work with some customers, but can't you see something cleaner?


    1. Converting to Java source code is, though feasible, really difficult. I would expect a language to gain enough adoption at some point, and be accepted. I guess, it was only COBOL that was considered "enterprise" once, but that had somewhat changed over time...

  30. Excellent set of languages features.  Particularly impressed with default non-nullable types, first-class delegation, and allowing arithmetic operator overloading.  Frequently overlooked language features like these plus an awesome IDE provides a compelling alternative to Java, where other JVM languages have come up short.  A few questions:

    • Why not use with implicit interfaces a la Go?  
    • Also, instead of supporting multiple inheritance (with an admittedly decent solution for the diamond problem) why not only support first-class delegation and implicit interfaces?  This provides most of the same functionality without the prone-to-abuse inheritance feature.  Any thoughts on dropping implementation inheritance altogether and just having first-class delegation (taking the best of Go and adding first-class delegation)?
    • Any plans to support immutable classes?  This is a missing feature in many languages and is very helpful for concurrency.
    • Speaking of concurrency, there is an excellent and very fast implementation of Actors on the JVM for Java called Jetlang (it's under the BSD license).  http://code.google.com/p/jetlang/  I saw that Actor-based concurrency was on the wishlist for post-1.0 Kotlin and figured Jetlang would be worth a look as to not reinvent the wheel.
    1. Aswering your questions

      1) Structural typing would require dynamic method signature resolution on the JVM. Although it is technically possible (e.g. with the new invokedynamic instruction), the runtime penalty is rather high.
      2) Delegation cannot fully replace inheritance, because when you override some of the delegated methods, the object you delegate to doesn't know about it, and if it internally calls this method, the old implementation gets executed
      3) I think we'll have this as a compiler extension. If you have any particular suggestions, they are very welcome.
      4) Thanks for the suggestion. We'll look into it.

      1. re: #3.  Although 'final' is a fine keyword (annotation), I miss dear old 'const'.

        1. const is a different thing, and we will probably provide an extension for const support

  31. Anonymous

    Are there any plans for Eclipse plugin?

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

  32. Any thoughts on specifying variable scope by convention like ruby?  Such as CONSTANT_CASE, @instance_variable, etc.?  And/or providing something similar to gofmt to ensure everyone uses the same style/conventions?

    1. It's hard to say what a "constant" stands for in Kotlin. And I don't think we will risk to annoy everyone with prefixed member properties.

      1. Anonymous

        My experience has been that if you don't, you will annoy everyone by having each person use a DIFFERENT prefixed member property. In the project I work with, due to various libraries we use as well as different people's coding styles, I see various fields named as:





        It is really annoying to see a single source file that ends up using three or more different conventions like this (it extends a class using one convention, but then the developer who created it used another, and the project who is now maintaining it uses another).

        I don't really care what convention is used to distinguish fields from class member variables, but I would really like the language to specify one so that I don't have to deal with the, er, "creativity" of my coworkers in their field naming choices. I think that this is something Ruby did well (using an @ to prefix field references). I'd like to see other languages follow this. (Personally, I prefer a leading underscore, but I would follow any standard that existed rather than trying to fight it.) The common place this is needed is in constructors, getters, and setters. Note that using a field naming prefix is often a defensive tactic: Note that, for instance:

        class Foo { 
         int absquatulation; 
         Foo(Something absqatulation) { 
         this.absquatulation = absquatulation; 

        Due to a typo, the above contains a semantic error that the compiler will not catch. If the code had been written like this, however:

        class Foo { 
         int _absquatulation; 
         Foo(Something absqatulation) { 
         _absquatulation = absquatulation; 

        the compiler would have correctly reported an error that there was no such variable as "absquatulation" in scope. Therefore, the prefixes do actually serve a useful value. However, having them all be different does not.

        Prohibiting self-assignment ("x=x") would be nice too.

        As far as constants, normally in the C/C++/Java family of language, UPPER_CASE is used for compile-time constants (public static final variables whose value can be known at compile time). This is one of the few formatting issues that almost all developers that I have seen agree on. I think this is a good idea, and I'd like to see the language encourage it.

        Please take some time to figure out a good, consistent way to format files, and it would be even better if the language encouraged or required it in many cases. Having everybody argue (forever!) about where to put the curly braces, and when, and if, is just a huge waste of time and a barrier to usability. (I've also seen code that has three different curly brace placement styles within the same file.)

        Also, I'd like to see mandatory curly braces around blocks. If a language requires this (like Perl, for instance) it can really reduce coding errors due to, for instance, the "dangling else" problem, or misplaced semicolons, in complicated structures.

        1. Anonymous

          Argh. The wiki's tedency to treat curly braces as the start of a macro can get annoying at times. Please fix the "Unknown macro:" in the above.

        2. Got your point. Thanks

  33. Anonymous

    Any comparisons to IBM's X10 language? The syntax seems similar.


      1. Thanks, Kotlin has annotations for most of the AST nodes too (including expressions)

    1. Thanks for the link. From the first sight the main difference is simply very different goals.

  34. Andrey,

    First of all i want to say thanks for all that you in particular and Kotlin team in general are doing. I really liked Kotlin. It's the first language i liked after i discovered Java to myself. And i think Kotlin has great future.

    I want to share this idea with you, it's not directly language-related.
    Are you allowing yourself to make a first test release of Kotlin and to experiment with it without having a constraint of backward compatibility for some time? If we'll look at good practical programming languages, that were becoming a tools for massive industrial software development we'll see that they were made after some experimenting.

    Before Java was released in 1995 it was called Oak from 1992 to 1995. It was a period of intense experimenting and testing of concepts. And even more: before that it took Gosling, Naughton, Warth, Frank and Sheridan 18 month to make first version of Oak to release it in 1992. The result is that Gosling himself calls Java a masterpiece (while creator is rarely being satisfied with his work) and from 1995 till today Java evolves cleanly and continues to drive innovation.

    It took Denis Ritchie some experiments with B in collaboration with Ken Thompson and close look to BCPL before he made C in collaboration with Brian Kernighan.

    Are you planning some evaluation period for Kotlin before setting first "hard" release with responsibility to hold backward compatibility?

    Thanks and Good Luck.

    1. Yaromir,

      Thank you for your kind words.

      We are certainly planning some evaluation period before we release Kotlin and fix the spec. It will be internal evaluation by JetBrains team, as well as a publicly available compiler with no guarantees for compatibility. We are looking forward to all the feedback we can possibly collect and take into account.

      Thanks again.

  35. One more question.

    I know it's too early to talk about this, but how do you plan to standardise Kotlin?
    I tried to study 3 cases:
    ISO working on C++
        Release of C+11 took 8 years after C+03 was released. Was there just some technical difficulties which took time to solve or their approach is obsolete?

    Java Community Process
        There was rather rapid evolution. One of the components of Java's success is that Java continuously accepts novation and, moreover, it creates novation by itself.

    WHATWG vs W3C working on html5
        Initially, they planned to defer the release of final spec until 2012 and there were more and more ideas to implement which, by the Ian Hickson's words could drag out the release till 2022. It ended up that they decided to move to iterative approach: rolling updates with snapshots.

    This brings me to the thought that "release-to-release" approach is really obsolete and a kind of rolling updates procedure can solve modern-world challenges. But i'm not quite sure about correctness of this conclusion. To further investigate this we need to compare organisational models and procedures in all 3 cases, which is hard work that will take a lot of time.

    Hope this was some help.

    Good luck in your hard challenge developing Kotlin.

    1. It's likely to be an issue of a rather distant future, but you are right, the issue is there, and when we get to it, we'll have to think hard ) Thanks for your comment.

  36. Anonymous

    "The main design goals behind this project are...": What about Kotlin having a execution speed similar to that of Java? So: compiles fast and runs fast...

  37. Anonymous

    Kotlin looks great, you might really fit in the Groovy/Scala gap.

    What will be the "preferred" way of supporting DSLs? In Groovy, it is quite easy to construct DSLs, it should be easy in Scala as well (haven't tried it yet).

    However, to me the easiest (though not cleanest) way is GEP 3 in Groovy:


    This could work in a statically typed language as well, couldn't it? Any plans to support DSL creation similar to this approach?

      1. Anonymous

        yes, this is pretty cool, however GEP 3 goes even further, because you don't have to use (curly) braces, dots or whatever.

        This makes the creation of DSLs a breeze. With builders, you would have to use at least braces, which IMO makes it more difficult for non-technical people to use it.

        Or is it possible to do this in a similar way in Kotlin and I just don't get it? 

        What I mean is a syntax like this:

        read file "data.csv" and store data in database

        read file "data.csv" and evaluate month september, 2011

        This can easily be done with GEP 3, where there is a certain convertion what call is converted to method arguments, method calls, etc.

        1. This kind of syntax is not impossible but can cause some confusion (plus it conflicts with our current annotation syntax, which is a minor issue). We'll think about it.

          By the way, I don't believe that any people for whom curly braces are a big deal can do any meaningful DSL coding whether in Groovy or in Kotlin, because if they make mistake, and the compiler throws an error at them, they wouldn't know what to do.

          1. Anonymous

            BTW I just saw that you wrote a blog post about this topic here: http://blog.jetbrains.com/kotlin/2011/10/dsls-in-kotlin-part-1-whats-in-the-toolbox-builders/

            So to me a combination of extension functions and infix calls (and builders) seems to be a good way of creating DSLs in Kotlin.

            Not as easy as "Command Expression based DSL" in Groovy, but statically typed and with IDE support (I suppose)

            which does more than compensate the slightly more complicated syntax.

  38. Anonymous

    Do you plan to do a PLEAC (http://pleac.sourceforge.net/) for Kotlin? This could leverage acceptance a lot.

    1. Good idea! We'll definitely do it. Thanks.

  39. Anonymous

    Some words on the Kotlin runtime library: There may be situations (I recently encountered one) where I can only ship one single jar file which should be able to work with a standard JRE without any additions (no classpath etc.). I this case I would include the sources of the Kotlin runtime into my jar. This is only reasonable if:

    • The Kotlin runtime is small.
    • Code relying on separate Kotlin runtimes can still interact "in a Kotlin way".
    • The license allows the embedding of the Kotlin runtime sources into commercial code.

    What do ou think? Is this a sensible way to go?

    1. Anonymous

      ...and maybe support this in the IDE: output a jar with the Kotlin code included?

      1. Anonymous

        i.e.: ...Kotlin runtime included.

      • The Kotlin runtime is small.
        • You don't even have to include all of the Kotlin runtime. The mandatory part of the Kotlin runtime is small. All the rest you can leave out if you don't use it.
      • Code relying on separate Kotlin runtimes can still interact "in a Kotlin way".
        • Kotlin runtime is a bunch of classes. On the JVM, same classes become distinct when loaded by different class loaders, so there's not way to pass objects between instances of the same library loaded independently, no matter what library it is: a Kotlin runtime or whatever. So, if you want to pass function objects or tuples between different parts of your system that do not share the same Kotlin runtime library, this will not work. Same for reified generics. On the bright side: everything else will work.
      • The license allows the embedding of the Kotlin runtime sources into commercial code.
        • Totally yes. The license will be Apache 2
  40. Anonymous

    Has any thought been given to transpiling Kotlin to JavaScript? There
    was a suggestion in this post http://www.infoq.com/news/2011/07/kotlin
    but I have not seen any other mention of a JavaScript target.

    What a pity Google didn't adopt Kotlin instead of Dart.

    1. We are planning to support a JavaScript target one day, but currently it is not a top priority.

  41. Anonymous

    Just for interest, what will be the extension for Kotlin source files? I'd object the most obvious *.kot extension, because it means "shit" in German. Just for you to know. Germans would appreciate using *.ktl or something similar a lot :)

    1. Don't worry, we use *.kt (smile)

  42. Anonymous

    Maybe it's too early to think about infrastructure around Kotlin, but i have some thoughts about unit testing in Kotlin i wanted to share.

    Is it possible to make single framework to avoid diversity of unit testing tools? And should this diversity be avoided at all?

    On one hand, if multiple unit testing frameworks appear, this means there is a necessity in them.
    On other hand for particular project we have problem not even of many unit tests depending on many frameworks by itself rather than a problem that the newbie quality engineer have to learn all of the frameworks. This takes time and adds barriers to involving new engineers to the project.

    D has an interesting feature - it has "unittest" keyword, but i don't like this solution and i can't explain why. I'm also interested in hardware development and i was pretty surprised when i saw a "testbench" keyword in Verilog. So we can see some cases when the same pattern of implementing testing capabilities on the language level rather that with frameworks is used both in software and hardware engineering.
    Of course, unit tests are not exactly the same thing as testbenches for hardware, but this two cases give something to think about.

    Or maybe it isn't worth thinking and we should just reuse Java UnitTesting frameworks within Kotlin interface to Java?

    What do you think about "keyword vs framework"?
    And, in general, what, by your opinion, should be added to language and what should be implemented as libraries and frameworks? JetBrains has a lot of experience in creating DSLs so i think you know this better.

    P.S. This is Yaromir, i forgot my password. :)

    1. Right now the plan is to provide a test framework for Kotlin as part of the standard library. Extension functions and closures make it possible to create a much nicer looking framework than good old JUnit, and we're going to make use of that. Obviously, writing tests in Kotlin using JUnit or TestNG will also be possible.

      We don't have any goal of avoiding the diversity of testing frameworks. If people want to explore different approaches to testing using Kotlin, that's just great from our point of view.

      As for language support for testing, we don't currently see any compelling need for that. Even if it turns out to be useful later, it's much more likely to be implemented as a compiler plugin and not as a core language feature.

      1. Hi Dmitry,

        Any news on unit testing?  Support in IDEA would be great.

        1. We are working on it right now

  43. Anonymous

    Are we gonna get an early Christmas present of an Alpha release of Kotlin?

    1. We'll keep it a surprise, anyway (smile)

  44. Anonymous

    I appreciate your work, but... there are a plenty of languages that share the same ideas of Java and C# only varying a little their syntax and introducing a lot of sugar. Fantom, Ceylon, Groovy++, Vala, Xtend, Nemerle, Boo, Mirah, etc (over 9000)...

    Kotlin is fully inspired of Scala and designed to be fully integrated with Java. But if it pretends to be a really useful language it must be cross-platform. So compiling for JVM, CLR, Android, JavaScript and using platform-independent API layer would be very nice. Another useful thing I see is cross-compiling Kotlin code to .java for GWT integration.

    1. All I can say for now is that we are working on compilers for some of the platforms you mentioned.

    2. Anonymous - that's a huge wish list.

      I think Kotlin can be useful without addressing all of your requirements.

      Do you want twenty mediocre capabilities or 5 great ones?

      I hope that JetBrains takes things one step at a time and gets the language and core libraries right first.


  45. Anonymous

    Добрый день!

    Вопрос автору языка: Вы не намерены сделать русскую версию языка, которая позволила бы программировать, не прибегая к латинице? 

    1. Добрый день.

      Нет, таких планов у нас нет, но любой желающий сможет это сделать, когда код проекта будет опубликован (это случится довольно скоро).

  46. Anonymous

    A language succeed by hitting its opportunity, Objective-C is the one, Scala have akka to bet, and what to kotlin?

    I ever used c, python, ruby, groovy, scala, java, Personally I like kotlin very much and have firm believe by trust jetbrains.

    Since java indicates less features, good for large amount developers in `labor intensive industry`, while several other languages try to serve brilliant ones. They are quite different.

    Scala is believed to be good for library developers, while build an ORM library(EBean - java, Squeryl..) or MVC framework(Play), they are all using the trick: code generation, or cglib-like staffs(maybe even struggle with classloaders).

    What a pity!

    If kotlin have restricted `macro`, that will be a huge feature to library developers.


    - liusong1111

    1. We are considering something like this for future versions

  47. I'm a big Groovy fan and IntelliJ IDEA Ultimate REALLY makes Groovy/Grails development even more pleasing.  I REALLY looking forward to playing with Kotlin.  I intend to be an early adopter.  Is there anything a mere mortal such as I can do to help?

    Thanks again guys for creating such a great IDE.  My team is the first in my company to switch from Eclipse and we are slowly gaining new advocates.  You guys really care about software.  Keep up the good work!

  48. I have a couple of random questions

    1) Is there any plan to include list comprehensions?  I find myself using them a lot in Clojure.  I think they are often a lot more readable than the equivalent higher order functions.

    2) If a class's properties are all vals will the compiler generate sensible default implementations of toString, hashCode and equals?  Like Scala's case classes and Clojure's records.

    1. 1) It depends on how readable our HO functions will actually be. We are currently working on them.
      2) The plan is to have an annotation on a class (like Scala's 'case') that makes the compiler do so.

  49. Edited: Found the answer to my async/await question, but can't delete post. As with everything else I really like your pragmatic approach, and look forward to working with Kotlin. 

  50. It will be possible to attach custom attributes to a property?

    In particular I'm thinking on a label or description to be shown in tooltips and forms

    1. Sure you can attach annotations to a property, although I wouldn't recommend to put UI stuff into the model code.

  51. hallo,

    is there any timeline for a public release of Kotlin (alpha,beta,...).

    1. A public preview of the IDE and the compiler will be out in February.

  52. Just a rant: I've read that to-JavaScript transcription isn't a prio yet — understandable considering the current dev state of Kotlin.

    You know that G is working on Dart which is just a better GWT, that is, Googlers will focus on creating a badass Dart-to-JavaScript transcriptor. Wouldn't it be better — instead of creating an own to-JS transcriptor — to transcript Kotlin to Dart and let Google's Dart-to-JavaScript transcriptor do the badass optimizations for you? Dart will be definitely syntactically & semantically closer to Kotlin than JavaScript can possibly be, also Dart is just like Kotlin (kinda [optionally]...) type-safe language, so is Kotlin.

    1. We reuse the back-end G uses for GWT and Dart. Translating Kotlin to another unstable language seems to be pushing "unstability" further than we are ready to push it (smile)

      1. Nice to hear that! My proposal wasn't so much about using Dart as an intermediate language but re-using what GWT already created and what Dart is creating and will create. Also I'd never recommend to use anything from Dart in the current dev phase.

  53. Congratulations for getting Kotlin out! I like the language: very much in the spirit of Scala, but without all that too many language features that cause the language to get scattered. Is there a language guide as a PDF or as a single page html? Then I could easier play a bit with Kotlin when being on the train to work.

    Regards, Oliver

    1. Hi,

      The best I can offer for now is this: http://dl.dropbox.com/u/31618705/kotlin-confluence-2012--03-16.zip
      A zipped collection of HTML pages. Viewable offline. I hope it helps.

    1. Does it give you an error message?

      1. No. Just artifacts list of the repository is empty.

        If click "Check now" on the "Edit repository" window shows messgebox with "Plugin descriptions contain some errors. Please, check idea.log for details."
        But idea.log does not contain information about it.

        Second xml-file contains wrong url (http://teamcity.jetbrains.com/repository/download/bt354/lastSuccessful/updatePlugins.xml)
        but i don't understand what is wrong at http://teamcity.jetbrains.com/repository/download/bt345/lastSuccessful/updatePlugins.xml

      1. Thanks. The problem was in the authentication.

        >Where did you get those urls?
        I took the urls from TeamCity.

  54. Some ideas for you from a guy in Oz with a passion for software engineering principles and quality...

    1) Take inspiration from Eiffel. Null safety is just the start (void-safety in Eiffel).
    Eiffel is the best designed language in the world and the JVM platform is most practical commercially.
    A merger of the two would be ideal. Kotlin comes closer than any language so far... keep going.

    2) The world needs design by contract(DbC). Use the full semantic model that Eiffel has proven - don't water it down as so many Java contract frameworks do. Make sure the contract assertions allow a label and/or free text names. Also implement a "contract view" of classes as documentation for the user of a framework (i.e. only the contracts of methods are shown, implementations are stripped out).

    3) Propose a clean subset of Kotlin as the new base language for MPS(its on their roadmap for 2013/4). This way Kotlin language extensions and DSLs will be done the way they should be: Opt-in and able to integrate with a wide variety of language extensions and DSLs because one company can't anticipate everyone's needs. Kotlin can be the foundation of the coming LOP revolution.

    4) Implement Simple Concurrent Object Oriented Programming (SCOOP) for Kotlin. It shares the same philosophy as Kotlin: Simplicity and ease for the engineer. Just like null safety it is added into the type system and in the case of SCOOP only a single additional reserved word is introduced to the syntax: separate. There is a good paper here on how implement SCOOP for Java: http://www.cs.utoronto.ca/~faraz/papers/cpa09.pdf

    5) Add opt-in Command-Query separation. i.e. functions that return a value should have no side effects. To remain compatible with Java semantics you need a mixed command/query methods. Consider adding two more method descriptors : "procedure" (void method with side effects) and "function" (method with no side effects returning a value or tuple) in addition to "fun".
    btw: I don't like abbreviations like "fun" and therefore "proc" and "func" are equally disliked - good language design should be human readable. Don't sacrifice readability for a little conciseness that actually obscures.

    6) Make Kotlin for AppCode a higher priority (i.e. LLVM, Cocoa etc). Kotlin could be a killer cross-platform development tool for core libraries.

    Thats enough for the moment.

    1. Thanks for the feedback and the encouraging words!

      1. No worries mate!

        Thinking further on DbC...

        Don't use annotations - Ughhh. Many contract frameworks tack it on and the expressions are all enclosed in a string which prevents syntax highlighting, refactoring, type checking etc DdC needs to be built into the language itself and so IDEA can work with it in the AST.

        Don't forget "check" assertions - they are also useful in addition to require, ensure and invariant.

        I was thinking along the lines of :

        (This is very close to how I implemented a simple DbC framework in groovy many years ago)

        This is not exactly following Eiffel, I have made the following improvements:

        1) Mandatory labels
        These are important as its good to have a human readable version of the assertion because:
        a) It aids the USER of a framework in understanding how to use it.
        b) It helps diagnose bugs when the label is added to a contract violaton exception then logged or alerted to the developer.

        2) Contract violation messages
        Added into the exception, these give more details about the offending values to help track bugs faster.

        3) Ordering is significant
        The second requirement is dependent on the first. i.e. if the first is violated the second is not relevent. This saves duplicating the first assertion in the second just to avoid multiple violations.

        4) Allow some variable initialisation code prior to requirement assertion in a method.

        On the topic of multiple violations perhaps there is an opportunity here to allow multiple violations and define the dependencies e.g.:

        In the case above the last two requirements could both be violated giving the developer more information up front.
        This means adding more than one contract violation to a single exception - perhaps this is too complex.

        OK enough.

        I am currently doing grails development for a startup and hope to convince the CEO to start phasing in Kotlin - wish me luck!

        If I succeed the first item on my agenda will be DbC so perhaps I can contribute at some point.

        PS: Is this the right forum to discuss language design? Is there a better place?


          1. Done. Posted in the Kontributors forum