Kotlin Census 2017

Posted on by Roman Belov

Hello!

Every year we run the Kotlin Census survey so we can get the latest feedback from you, and how you are using Kotlin in your projects. If you still don’t use Kotlin, we would like to understand your reasons why and your opinion of the language is exceptionally important for us as well. If you filled out the survey last year, thank you, it would be really helpful if you could please do it again: we’re interested in the up-to-date information, we’ve also added a few new questions and response options based on last year’s results.

As such, we’re asking you if you could kindly give us two minutes of your time and fill out the following survey.

Please note that by providing us with your details, you are not automatically giving us consent to use your name, application or company name. We would always ask for written confirmation from you before doing so.

Thank you!

Comments below can no longer be edited.

76 Responses to Kotlin Census 2017

  1. Даниил Водопьян says:

    July 14, 2016

    We also allow inlining property accessors now
    It looks like the discussion for this feature is halted due to the lack of technical motivation https://github.com/Kotlin/KEEP/issues/34. What is the chance this goes into 1.1 ?

    • Andrey Breslav says:

      July 14, 2016

      It looks like the discussion for this feature is halted due to the lack of technical motivation

      Why do you think so? The chance is about > 70%.

      • Даниил Водопьян says:

        July 14, 2016

        Well, I can’t find a “motivation” section anywhere, so I assume nobody bothered to make one.

  2. Sergey Grekov says:

    July 14, 2016

    Bear in mind that async library actively uses CompletableFuture from JDK 8, so it will not work with earlier versions.

    No async/await on Android?(

    • Simón Oroño says:

      July 14, 2016

      Maybe it was used just for prototyping?

    • Sergey Mashkov says:

      July 14, 2016

      You can implement async/await functionality on top of other libraries: CompletableFuture implementation is just a reference implementation.

    • Andrey Breslav says:

      July 15, 2016

      That’s an example prototype implementation. Will likely be included with the standard library, but the design allows you to write many async libraries for many platforms. Feel free to write one for Android before someone else did 🙂

      • Marcel Bradea says:

        July 26, 2016

        Anyone working on a Bolts implementation?

        Bolts was designed after the .NET Task library which C#’s async is built upon. It would be great to use this model as a baseline inspiration since it is mature and has a lot of reference examples to go on (between Bolts and C# together). If anyone is working on this plz post a Github link – happy to contribute.

        • Andrey Breslav says:

          July 26, 2016

          I haven’t heard about such work, but it would make sense to ask about it in our Slack

  3. Edwin Dalorzo says:

    July 14, 2016

    Awesome! I am stoked to see the great progress the Kotlin team is making with the language. This steady pace is what helped me convince my team to start using Kotlin to build our next microservices project. After a few weeks using it, we don’t want to go back to Java.

    Keep up the good work guys. This is looking great! I can’t wait for the release 1.1 to be production ready.

  4. Kingsley Adio says:

    July 14, 2016

    Awesome!
    I have a question here though

    we introduce new artifacts: kotlin-stdlib-jre7 and kotlin-stdlib-jre8 that carry extra functionality
    

    Will a project using the kotlin-stdlib-jre7 or kotlin-stdlib-jre8 be able to generate jre6 bytecode?

    • Eugene Krivenja says:

      July 14, 2016

      No, I guess

    • ilya.gorbunov says:

      July 15, 2016

      Yes, actually these artifacts are compiled to JVM6 bytecode as well.

      • Kingsley Adio says:

        July 15, 2016

        Good to know it’ll be JVM6 compatible.

        How will this work though? Constructs like jre7 try-with-resources or jre8 lambda and default methods will be compiled to Kotlin’s equivalent?
        How will this affect usage of the stream API? Will there be some sort of compatibility library bundled with the resulting binary? Or some sort of call site inclining maybe? Or does the app just crash at runtime?

        Thank you

        • Andrey Breslav says:

          July 15, 2016

          Library and bytecode version are two separate things. JVM6 bytecode doesn’t mean Java 6 compatible. If you code compiled to JVM6 bytecode format uses Java 7 classes, it will fail on Java 6, because those classes will not be found.

          Default methods are a feature of JVM 8 bytecode format, so they are not present in any code compiled to JVM 6.

          • Kingsley Adio says:

            July 15, 2016

            Ah. True. Pardon me. I just immediately assumed the lot. Thanks for the clarification.

  5. Mohammad Sarbandi says:

    July 14, 2016

    I remember, there was so many discussions about array, list and map literals. any update about that?

    something like groovy or phantom literals would be awesome:
    val list = [1, 2, 3] // list and array
    val map = [1: “one”, 2: “two”] // map

    • Kenny says:

      July 15, 2016

      Agreed. These would be convenient.

    • Andrey Breslav says:

      July 15, 2016

      These haven’t made it into 1.1 yet, but we’ll see

    • Brendan Murphy says:

      August 2, 2016

      Seconding this.

    • Josue Rios says:

      August 8, 2016

      +1. This needs to happen.

  6. Daniel says:

    July 15, 2016

    Nice work, guys!! 😀

  7. JVM-Sprache Kotlin: Kotlin 1.1. – die erste Preview ist da! [Update] - JAXenter says:

    July 15, 2016

    […] gibt Neuigkeiten aus dem Hause JetBrains: Die erste Preview von Kotlin 1.1 wurde veröffentlicht. Auch wenn die Entwickler betonen, dass es bis zur Beta noch ein langer Weg ist – die Preview ist […]

  8. Vladimir says:

    July 15, 2016

    I’m not sure that I like “implicit” coroutines nature. For user they look like a normal code, but it’s not a normal code. Some keyword to indicate suspension point may be. But I probably have to try that first.

  9. Jacob Zimmerman says:

    July 17, 2016

    I’m so glad you guys found ways of doing all the coroutine-esque stuff with functions, AND with them still being nearly as easy to use as keywords. I like where this is going. You’re taking the functional style to heart.

  10. Jaen says:

    July 20, 2016

    I don’t think this works with coroutines?

    val future = async<String> {
        (1..5).map {
            await(startLongAsyncOperation(it)) // suspend while the long method is running
        }.joinToString("\n")
    }
    

    Isn’t map a higher order function? In this case, the await is executed inside the closure passed to map, meaning that unless some “magic” is happening, map is returning a List<Continuation>, not List, and you can’t call .joinToString() on that.

    • Andrey Breslav says:

      July 20, 2016

      I don’t think this works with coroutines?

      Well, it does 🙂 map is a higher-order function indeed, but it’s also an inline function, and the compiler can emit a suspension point inside an inlined lambda.
      Also, await() does not return Continuation, but rather the result of its argument’s execution, i.e. startLongAsyncOperation(it), so yes you can call joinToString() on that.

  11. Mohammad Shamsi says:

    July 20, 2016

    This is lovely. with type aliases I can add extension function to function types.

    typealias Parser = (State) -> Reply
    
    infix fun Parser.or(other: Parser): Parser = decide(this, other)
    
    • Даниил Водопьян says:

      July 20, 2016

      That was possible in 1.0:

           infix fun ((State) -> Reply).or(other: (State) -> Reply) = decide(this, other)
      
      • Mohammad Shamsi says:

        July 20, 2016

        You are right. I had never tried that before.
        But the one with typealias is clearer and more readable.

        Thanks for the hint.

  12. Revue de Presse Xebia | Blog Technique Xebia - Cabinet de conseil IT says:

    July 21, 2016

    […] De nombreuses nouveautés restent à découvrir dans l’article First glimpse of Kotlin 1.1 […]

  13. HE Guangyu says:

    July 27, 2016

    Great works!

    On coroutine, org.fusesource.hawtdispatch is a cool implementation. We use it in a productive enviroment instead of Thread, the CPU load is decreased dramatically, about 1/10 of the origin.

    Also, it’s API is very simple to use.

    When I use Hawtdispatch, I can create many queues(a queue, like a light Executors), and I can run my code in the differnt queues. I think this is the most important part of coroutine.

    In HawtDispatch, we write:

    val queue1 = Dispatch.createQueue()

    queue1.execute {

    }

    In Kotlin coroutine, we write:
    async {
    }

    Can we control the executing order of differnt coroutine, liking Hawtdispatch does?

  14. Cliff says:

    July 31, 2016

    Could it be that the lifting of inheritance for data classes is not yet present in 1.1-M01?

    A contrived example:

    data class Currency(var name: String) {}
    class Euro : Currency(“Euro”)

    I am getting “This type is final, so it cannot be inherited from.”

    • Cliff says:

      July 31, 2016

      Please correct inquiry to read:

      class Euro : Currency(“Euro”)

    • Andrey Breslav says:

      August 1, 2016

      One can not inherit from a data class. But a data class can be inherited from another class.

  15. Cliff says:

    July 31, 2016

    TypeAliases are super cool and very welcome indeed. Much more than just a convenience. In an initial test, I notice that they are not exposed to Java calling classes. Anything special I need to do?

    • Andrey Breslav says:

      August 1, 2016

      There’s no way in which type aliases can be exposed to Java and preserve semantics. They are a Kotlin-only syntactic convenience.

  16. kirillkh says:

    August 3, 2016

    I added the line “maven { url “https://bintray.com/kotlin/kotlin-eap-1.1/” }” to my build.gradle (under buildscript.repositories), but it gives me an error:
    Error:Could not HEAD ‘https://bintray.com/kotlin/kotlin-eap-1.1/org/jetbrains/kotlin/kotlin-gradle-plugin/1.1-M01/kotlin-gradle-plugin-1.1-M01.pom’. Received status code 500 from server: Internal Server Error

    • kirillkh says:

      August 3, 2016

      Figured it out: you need to add “dl.” as a sub-domain, i.e.
      maven { url “https://dl.bintray.com/kotlin/kotlin-eap-1.1/” }

  17. Hans says:

    August 4, 2016

    Nice! I don’t really understand how this

    
    val memoizedFoo by lazy { foo(bar) }
    
    // use memoizedFoo instead of foo to get it computed at most once
    if (someCondition && memoizedFoo.isValid()) {
        memoizedFoo.doSomething()
    }
    

    is better than

    
    val memoizedFoo = foo(bar)
    
    // use memoizedFoo instead of foo to get it computed at most once
    if (someCondition && memoizedFoo.isValid()) {
        memoizedFoo.doSomething()
    }
    

    Are kotlin-stdlib-jre7 and kotlin-stdlib-jre8 only for Kotlin 1.1? Also, and sorry if this is a bad question, but can I enable -jvm-target 1.8 via gradle.properties?

    Best regards
    Hans

    • Andrey Breslav says:

      August 5, 2016

      On lazy: in the second case memoizedFoo gets computed only if it’s used.
      I’ll redirect the rest to my colleagues

    • ilya.gorbunov says:

      August 5, 2016

      kotlin-stdlib-jre7 and kotlin-stdlib-jre8 indeed are only for Kotlin 1.1, as they depend on changes in kotlin-stdlib. In Kotlin 1.0 you can get part of that new API with the support library: https://github.com/Kotlin/kotlinx.support

      You can enable jvm-target 1.8 in gradle with the following option:

      compileKotlin {
          kotlinOptions.jvmTarget = "1.8"
      }
      
  18. Alwyn Schoeman says:

    August 6, 2016

    Will the backwards compatibility to 1.6 ever become limiting to the enhancement or efficiency of the language? Or is it just a matter of whatever technology is in kotlin will also be available in 1.6 due to custom 1.6 runtimes?

    • Andrey Breslav says:

      August 9, 2016

      We support higher targets (currently 1.8) along with 1.6. Some features may work significantly faster in 1.8, but the promise is that we provide for reasonable performance on 1.6 as long as there’s enough users to justify that. It has not hindered the design so far, and I do not expect it to.

      • Cliff says:

        August 9, 2016

        Fair enough. I would however welcome a reversal of the VM flag so that it is required for 1.6 but not for 8, instead of the other way around.

        • Andrey Breslav says:

          August 9, 2016

          Interesting point. We’ll think about it. Thanks

  19. Bosh says:

    August 8, 2016

    Please Please!
    I am very sorry ! I am a newbie here, so much interested here but who can help direct me to where i should start from to get it in shortly.
    I am new to kotlin and thinking of using it for Android Development.
    Thinking and very convinced kotlin is the better choice ahead of java.
    Hope someone can help on this.
    regards!
    Bosh

  20. BabeDev says:

    October 18, 2017

    Kotlin is great

  21. Fernando Franco Giráldez says:

    October 18, 2017

    have you mistake katz library with kategory.io?

    • Roman Belov says:

      October 18, 2017

      Indeed. Thanks for the notice. Will fix it.

  22. Rivu Chakraborty says:

    October 18, 2017

    A certification on Kotlin from jetbrains would be great.

    • Andy Marchewka says:

      October 18, 2017

      Love that idea! With a functional programming component, coroutines, and specializations for Android, JavaScript, HTML, etc.

    • Louis CAD says:

      October 18, 2017

      Your open source code on GitHub can be your certification 😉

    • mdevs says:

      October 19, 2017

      That would produce a legion of “certificated” developers who don’t know sh** about programming; Just like what happens in Java. Maybe it would be a good idea if passing it is extremely difficult, and with extremely difficult I mean <15% of applicants would finish the process.

      • Alexander says:

        October 19, 2017

        You are not quite right. From our experience (a big IT company), the guys who pass Sun Certified Java Programmer exam with score > 80% (we require it internally) are quite knowledgeable in Java and do not make false assumptions about language and API. This does not prove they can develop things, of course, but you shouldn’t consider only exam certificate when hiring devs, should you ?

      • Antekm says:

        October 25, 2017

        I remember that learning for Java certification years ago was a good occasion for me to explore and learn some more obscure aspects of the language (and in general some things that I didn’t know so well)

        With Kotlin being rather new (at least in terms of adoption) having certifications could make up for lack of experience in this specific language (that can be a factor for people who might decide not to go for Kotlin as there’s no one with good experience in it in the company)

  23. Roman Doboni says:

    October 18, 2017

    Can you pls put the submit button near the “accept terms …” checkbox? Took me a while to find it on mobile.

    • Rakshak R Hegde says:

      October 19, 2017

      Yeah, on mobile submit was hard to find. Please fix.

  24. Mike says:

    October 18, 2017

    For those who may be filling this out on mobile (at least on Android Chrome), the “Submit” button is fixed to the very bottom right corner of the page.

    • Nils Breunese says:

      October 19, 2017

      Thanks for that, I don’t think I would have found it (on my iPhone SE) without this comment.

  25. Jonathan D'Orleans says:

    October 19, 2017

    I work heavyly with ML and AI and would love to have Kotlin as a primary language in the field instead of Python. I’m also working on openning a few libs to help this movement. Thx for the great work!

  26. williamwallace says:

    October 19, 2017

    kotlin is simple, beautiful, efficient Android language

  27. Arslan Charyyev says:

    October 19, 2017

    Please allocate more human resources to android support. For instance anko is fascinating and promising library, but lack of documentation and a single maintenainer makes it impossible to use it in production reliably. Thank you.

    • Ivan Molchanov says:

      October 21, 2017

      +1 Totally agree.

  28. John says:

    October 19, 2017

    What I’d love to see from you guys, are some production quality examples on github with proper project structure and “kotlin-way” of writing code, so people can follow some guidelines and produce good code.
    As with all available code snippets and “hello world” examples in “main” method is not enough to teach people to write good quality code.

  29. Marcel Bradea says:

    October 19, 2017

    Honestly after being on Swift and Kotlin straight for the past 2 years, it’s clear Kotlin is much further behind Swift at a holistic, production-quality level.

    For example, the lack of language-level array/dictionary subscripts and having to use library-level functions for simple nullable logic (ie: instead of Swift’s powerful “if let ….” / “case let …” ), let alone the whole mess around Delegates.observable and the various limitations of mixing them with ‘lateinit’, lazy etc. makes Kotlin feel very half-baked and immature still. There is still no proper way to check whether something has been late-init-ed yet (ie: Swift’s ‘trust-me’ operator ) and thus several scenarios around lazy-loaded data have to be mis-modelled as optionals instead of conditional late-inits. These kinds of things showcase that there were a lot of great POCs in the language in the exploration of introducing nullables/read-only to the JVM – but those things were never re-examined and re-designed ground up in the language. And that’s a damn shame.

    The fact that resources are being poured into going cross-platform (JS, Native) is a clear mis-prioritization as it’s going to spread the half-baked state of the language further and make it orders of magnitudes harder to make these much-needed changes – ie: or worse yet never happen. We saw this happen with Java VS C#, where Java got stuck a decade behind based on the premature opening and spreading of unproven approaches. It is happening right now for Kotlin VS Swift and I don’t want to see you guys fall in the same trap.

    As it stands, compared to any other JVM language Kotlin takes the crown, and you guys have achieved incredible things to take Java and Android forward into the modern age. But ’tis not yet the time to bring it outward to other platforms, this is the time to fix everything from all the lessons learned and from the inspiration you’ve gained from Swift – and make Kotlin a truly great language that’s WORTH bringing to other platforms.

    I hope you guys seriously reconsider this prioritization and focus again on making Kotlin better/cleaner/meaner. The alternative is that Swift WILL go cross-platform at some point (Silver is already on it – http://elementscompiler.com/elements/silver/), and once that happens Kotlin will be behind in a way that you will never be able to catch up / compete.

    • Evan Nelson says:

      October 19, 2017

      “For example, the lack of language-level array/dictionary subscripts and having to use library-level functions for simple nullable logic (ie: instead of Swift’s powerful “if let ….” / “case let …” )”

      I disagree. I think that JetBrains’ decision to make these things library-level instead of language-level is the right choice. Why does the language itself need to have built-in support for things that can just as easily be implemented as library functions? That makes the language heavier and thus harder to maintain. To be honest I’m disappointed that they’re adding array literals, but that one was just too popular in the last survey.

      • Ole Sandum says:

        October 20, 2017

        I wholeheartedly agree. When I first saw they’re going to be adding array literals I was confused as to why. I still don’t get it.

      • Marcel Bradea says:

        October 23, 2017

        Perhaps the same reason such as any language feature is useful. For brevity, adoption and moving our industry forward.

        The same could be set about C# Task library. Why bother adding ‘async’/’await’ keywords? Because they were able to achieve an order-of-magnitude improvement in simplicity and adoption when they did. The way the go there was indeed to introduce it as a library-only feature for an entire generation of the language – and to stabilize it and bring it into the language once they were confident in the implementation/syntax.

        We should not settle for anything less with Kotlin. It’s okay to start at libraries to get the POCs out and collect feedback from the community – but especially with Swift leading the way and showing us mature, proven ways that it can be done, Kotlin should aim to minimize time spent in incubation for features and evolve the language / simply syntax – and stay closer to par with the growing alternative (Swift).

    • Gerald says:

      October 20, 2017

      Agreed. Jetbrains should concentrate their resources on polishing Kotlin.

  30. Gert Claeskens says:

    October 19, 2017

    Or ‘Kotlin Kings’ in analogy with Java Champions 🙂

  31. Eric W Clarke says:

    November 15, 2017

    Looking forward to learning more

Subscribe

Subscribe for updates