Kotlin/Native IDE Support Preview

Roman Belov

Kotlin/Native is a brand new technology that compiles Kotlin directly to machine code and produces executables that can run without a virtual machine. At KotlinConf 2017, we announced a preview release of development tools for Kotlin/Native.

While we have IntelliJ IDEA for working with Kotlin, Kotlin/Native integrates with technologies from the native world such as Clang and LLDB support. That’s why JetBrains’ choice for Kotlin/Native is CLion, our IDE for C and C++.

To get started, download and install CLion 2017.3 (note that this version is at the early access preview stage for now). Next, install two plugins from the JetBrains Plugin Repository. In CLion, choose Configure → Plugins → Install JetBrains plugin…, then find Kotlin and Kotlin/Native plugins there, and install them. Don’t forget this is still a technology preview and bugs are possible, but if you encounter any, please report them!

New Kotlin/Native Project

Learning a new technology requires a good entry point, and we’ve already prepared one for you. Create sample projects right from CLion and play with some simple code examples. Click *New Project → Kotlin/Native Application *and select one of the available samples. CLion will automatically download and install native packages on your computer as needed.
NewProjectDemo

Code Insight

Kotlin/Native IDE support is based on the regular Kotlin plugin for IntelliJ IDEA. This means that you have all the specific code inspections, intentions, code completion actions and of course refactorings already available for Kotlin/Native!
KotlinCodeInsight

Debugging

The CLion plugin supports debugging, based on LLDB. Note this is still under active development and requires specific conditions (plus a bit of luck) to get working. Please do try it and let us know how it works for you!
debugging

Kotlin/Native Tests

The CLion plugin also supports running tests written using the kotlin.test framework. For the time being, to run a test, you need to create a ‘Kotlin/Native Test’ run configuration (under Run → Edit Configurations…) manually. Creating configurations from the editor popup menu will be supported in future updates.

Once you run the tests, you will see a nice test tree like this one:
testing

What’s Next?

IDE code insight, testing support, and a debugger are already a pretty solid tool-set, and we’ll continue to polish these features to make your experience as smooth as possible for the public release. However, it’s not everything we plan to offer with the first stable release of Kotlin/Native IDE support. We are also going to fully support interoperability with native libraries, with features such as documentation preview, cross-language navigation and, of course, refactorings.

Have a nice Kotlin/Native!

Comments below can no longer be edited.

46 Responses to Kotlin/Native IDE Support Preview

  1. Dariusz Baciński says:

    April 7, 2017

    Is there a way to see the current results of Kotlin Future Features Survey?
    Or do you plan to publish results in the future?

    • Alina Dolgikh says:

      April 7, 2017

      We will publish the results in a few days after the voting is completed. We are going to complete it round about April 17.

      • Pavel Sikun says:

        April 23, 2017

        April 17th already passed. Can we expect to see the results soon?

        • Alina Dolgikh says:

          April 24, 2017

          Yes, you can see them soon. We have prolonged the survey for one more week. Tomorrow we will finish it and prepare a report approximately in 1-2 weeks.

  2. eugene says:

    April 7, 2017

    please, add ternary operator)))

    • Christian says:

      April 7, 2017

      Noooooooooooooooo!

    • Andrew Grosner says:

      April 8, 2017

      Ternary for the win! I hate the if else for simple conditions

  3. Christian says:

    April 7, 2017

    I’m worried by two of the proposals:

    1) “Private members accessible from tests”

    I absolutely disagree with the rational behind it, since the coupling between tests and the actual implementation is very relevant for long term maintainability. Destroying encapsulation for testing would only encourage to write even worse tests!

    2) “Static members in Kotlin classes”

    It is much cleaner with objects and Scala has proven that it is possible to live without static elements. Don’t pollute the language with it. At least you could wait a bit an see if the desire is not mainly from Java programmers new to the concept of object literals.

    • Christian says:

      April 7, 2017

      See also “TDD Harms Architecture” by Uncle Bob
      http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html

    • Dariusz Baciński says:

      April 7, 2017

      Very good points. Totally agree.

      I love how hard it is now to do things that are bad practices.
      Introducing statics and testing private methods will definitely help to write not maintainable code.

    • Al says:

      April 9, 2017

      I’m a relative novice to programming and Kotlin’s my first statically typed language. My interest in it is largely because of the following:

      More safety automatically.
      Full Java interoperability and the ability to use it for developing on Android too.
      I haven’t actually tried Scala but Kotlin has the reputation of being easier at the cost of some power. The way I see it is that Java’s need for backwards compatibility lead to some less than elegant solutions (generics) and stagnation so both Kotlin and Scala are step-ups.

      Many of the complaints I saw about Scala lie in the idea that it tries too hard to be everything and that its expressiveness gives so much freedom that it’s hard to read other people’s code.

      On the other hand, Go is extremely opinionated and lacks many modern features like generics. This makes many people hate it and it definitely feels like a step back in many ways. However, the ones who like it often heap praise on it for how easy it is to read other people’s code and maintain software.

      I hope Kotlin will stay as a simple, safe and modern alternative. I also think there’s great value in a language being opinionated as long as it still has the power to easily let you do whatever you want in that “one right way.” Opinionated languages are so much easier to read and maintain.

    • Ivan Molchanov says:

      April 10, 2017

      I also voted for banning static members in classes.

  4. M says:

    April 24, 2017

    I hope that I’m not too late to give my input on this.

    Since the keyword “in” has multiple uses and assignments are never allowed in a control structure, I think that it would make sense to use the keyword “as” outside of the parentheses like so:

    when (some_expression) as variable {}

    That way, there is no confusion over when an assignment is allowed in a control structure and there is no ambiguity in the use of the keyword “as” in this syntax.

  5. João Vitor Verona Biazibetti says:

    November 4, 2017

    Will it be exclusive for CLion, or there are plans for also making it availabe on IDEA?

    • innov8 says:

      November 4, 2017

      It would be ideal if all could run under Intellij. Quite reasonable if a CLion license is required to a CLion plugin – JetBrains has to have a revenue path so they can devote resources to the project… but still optimum if all projects can be under the same ide

    • Alexander Podkhalyuzin says:

      November 7, 2017

      Main development is focused on CLion right now as we have lldb support in it and don’t have it in IntelliJ IDEA. As it’s just preview and we need to invest a lot of efforts to make it production ready, we don’t have any plans for IntelliJ IDEA right now, but I can’t say it’s impossible in future.

      • Michael Lawrence says:

        November 16, 2017

        If you guys are serious about WASM support I would think WebStorm would be a viable candidate for IDE support as well. Being able to write my JS and Kotlin/WASM code in the same editor would be awesome. 🙂

  6. Markus says:

    November 4, 2017

    Is there any writeup on how dependencies will be managed?
    Will there be some kind of package manager which can download artifacts (like maven for example) in the future?

    • Scellow says:

      November 4, 2017

      +1 i hope a good package manager will be in place!

    • Alexander Podkhalyuzin says:

      November 7, 2017

      We are going to support it in some way, but currently we don’t have answers even what to distribute, if it should be sources, binaries or even something else. But this is definitely what we actually want to have, so it’s going to be implemented.

  7. Maarten says:

    November 4, 2017

    Can you say anything about a timeline for adding Kotlin/Native support to AppCode?

    • Stanislav Dombrovsky says:

      November 5, 2017

      We will decide later, cannot give any ETA right now.

  8. Gordon says:

    November 4, 2017

    Good work, thanks teams!

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

    November 4, 2017

    What build system will be the default for mixed projects? Gradle, CMake? What format will be used for native library distribution? Jars, something else?

    • Alexander Podkhalyuzin says:

      November 7, 2017

      Currently native libraries uses own format ‘klib’. We don’t have information yet about package repositories for binaries/sources (or something else), so it’s just a file for now.
      Currently Kotlin/Native supported in both Gradle and CMake, however if you want to open project in CLion, you have to use CMake (it will be changed in future). So it means that mixed projects has to use both CMake and Gradle, however how such project should look we are not ready to tell yet, but work is in progress.

  10. Sergey says:

    November 5, 2017

    How to is setting IDE?

    • Alexander Podkhalyuzin says:

      November 7, 2017

      What did you mean exactly? If it’s about general instructions, then just download CLion 2017.3 EAP and install two Kotlin plugins, then you will be able to create new Kotlin/Native projects.

      • Sergey says:

        November 9, 2017

        Example projects does not gather, asks to specify MinGW, CMake etc.

        • Sergey says:

          November 9, 2017

          How to fix it? https://ibb.co/b7QG7b

          • Alexander Podkhalyuzin says:

            November 10, 2017

            Windows is not yet supported, we are going to support it soon.

            • Sergey says:

              November 10, 2017

              Ok, thanks.

  11. Augusto says:

    November 5, 2017

    How garbage collector works in kotlin native?

    • Nikolay Igotti says:

      November 6, 2017

      See https://github.com/JetBrains/kotlin-native/blob/master/RELEASE_NOTES.md, i.e.

      Currently Kotlin/Native uses reference counting based memory management scheme with a cycle collection algorithm. Multiple threads could be used, but objects must be explicitly transferred between threads, and same object couldn't be accessed by two threads concurrently.

  12. Frederic Janicki says:

    November 5, 2017

    That sound great! Is there any samples of using this for MCU / Embedded development?

    • Nikolay Igotti says:

      November 16, 2017

      Not yet, however there’s no fundamental reasons why it couldn’t be done.

  13. kotliner says:

    November 6, 2017

    Kotlin native is great! kotlin is the only language to support pc, mobile ,web(javascript, wasm).
    support PC: windows, linux, Mac OS
    support Mobile: iOS, android
    support Web: javascript and WASM

    but I hope kotlin support UWP also, what I means is the kotlin standard library for thread, network, and etc will support windows UWP(uwp is very different, don’t support normal c11 thread, tcp/ip socket, etc ). In fact, from 2020, almost all windows platform will support UWP.

    if kotlin standard library support pc , mobile , web and windows uwp from it’s beginning, then kotlin will be the only super language which support nearly all platform!

    kotlin is great!

    • nilof says:

      November 17, 2017

      Reminder: the language supports many platforms, but most third-party libraries won’t. Library ecosystems are typically harder to learn than languages. Changing from Kotlin to Swift is effortless since the two are almost the same language, changing from Java ecosystem libraries to Objective-C ecosystem libraries is a much bigger adjustment.

  14. Mike says:

    November 6, 2017

    OMG – Kotlin is really hot. Native support rocks.

  15. says:

    November 7, 2017

    How to create Chinese-characters version kotlin?

  16. huodon says:

    November 7, 2017

    Package manager +1

  17. Clancy says:

    November 8, 2017

    It seems that currently Kotlin/Native uses “native” iOS controls. Is this a requirement or will it be possible to use the compiled Kotlin to access/port a lightweight UI framework like JavaFX?
    Will it be possible to utilise native C or C++ libraries in a Kotlin/Native app?
    Will it be truly cross-platform with eventual support for Windows, MacOS, Linux, iOS, Android and embedded with minimal platform-specific code?

    Performance of the KotlinConf app on my iPhone is awesome – well done!

    • Alexander Podkhalyuzin says:

      November 16, 2017

      I can’t say if we are going to implement some lightweight UI framework or not as we don’t know yet ourselves too, so for now it’s requirement, but anything is possible in future.
      You can use native C library in Kotlin/Native app, but not C++.
      It’s not intended to be truly cross-platform for now as it’s much more complicated task. However I’m pretty sure that in future JetBrains together with community will implement lots of platform-independent Kotlin libraries especially for Android/iOS.

  18. david says:

    November 10, 2017

    Package manager ++
    More powerful construction tool

  19. Krzysztof says:

    November 15, 2017

    When Windows will be supported would I be able to create dlls libraries? If so – when?

    • Alexander Podkhalyuzin says:

      November 16, 2017

      Windows in CLion is going to be supported soon, however I can’t say the same about dlls. It’s under active development, but if it’s going to be in Kotlin/Native 0.5 or not, I can’t say, as it’s too early for that.

  20. Wyatt says:

    November 17, 2017

    I understand that Kotlin/Native is very new and experimental right now, but once you have pushed past the current set of hurdles, when do you think performance optimization can become the focus? With LLVM’s atom structure and information available from Kotlin semantics, you could probably squeeze some radical optimizations out of this. Any projections on when you might match or exceed the current JVM performance with native code?