Kotlin/Native Tech Preview: Kotlin without a VM
We are happy to announce the first Technology Preview of Kotlin/Native that compiles Kotlin directly to machine code. The Kotlin/Native compiler produces standalone executables that can run without any virtual machine.
It is not a fully functional release yet, but you can already play with the technology and take a look at its source code here. The compiler is available under the Apache 2 OSS license.
Mission
Kotlin/Native is another step toward making Kotlin usable throughout a modern application. Eventually, it will be possible to use Kotlin to write every component, from the server back-end to the web or mobile clients. Sharing the skill set is one big motivation for this scenario. Another is sharing actual code.
Our vision for inter-platform code reuse is the following: one can write entire modules in Kotlin in a platform-independent way and compile them for any supported platform (currently these are Kotlin/JVM, Kotlin/JS and the upcoming Kotlin/Native). We call these common modules. Parts of a common module may require a platform-specific implementation, which can be developed individually for each platform. Common modules provide a common API for all clients, but other (platform-specific) modules can extend this API to provide some exclusive capabilities on their platform.
Note that we do not intend to make arbitrary Kotlin/JVM programs runnable on Kotlin/Native or Kotlin/JS. It would be equivalent to implementing another JVM, which is both a lot of work and a lot of limitations for the runtime. We are going another way: providing a common language for all platforms while enabling creation of common libraries through seamless interoperability with platform code.
Technology
Kotlin/Native uses the LLVM compiler infrastructure to generate machine code. In this preview, we support the following target platforms:
- Mac OS X 10.10 and later (x86-64)
- x86-64 Ubuntu Linux (14.04, 16.04 and later), other Linux flavours may work as well
- Apple iOS (arm64), cross-compiled on MacOS X host
- Raspberry Pi, cross-compiled on Linux host
More platforms can be added relatively easily, as long as the LLVM support is available for them. We will probably support a few more platforms out-of-the-box in the future.
As usual, interoperability is among our top priorities, and Kotlin/Native can efficiently call C functions and pass/get data to/from them. You can generate Kotlin bindings from a C header files at build time and get fast type-safe access to any API native to the target platform. See detailed instructions here.
Memory management
Kotlin/Native is designed to potentially enable different memory management solutions for different target platforms. For example, in the future it may make sense to have a tracing GC for server/desktop platforms, while ARC makes a lot more sense on iOS. Some platforms may only need manual memory management, and get an even smaller Kotlin/Native runtime in return.
This Technology Preview features automatic reference counting with a cycle collector on top, but what the final memory management solution(s) will look like is unknown at this point.
Current limitations
As mentioned above, Kotlin/Native is far from complete, so this Technology Preview has a number of limitations that will be eliminated at later stages:
- No performance optimization has been done yet, so benchmarking Kotlin/Native makes no sense at this point.
- The Standard Library and reflection support are far from complete, more APIs will be added later.
- Read more in the Release Notes.
Future plans
We are currently working on the core technology for Kotlin/Native which is the same for all target platforms (compiler, core runtime and library). As a matter of possible future work, we are considering the following possible use cases:
- iOS applications (reusing code with Android)
- Embedded systems/IoT (e.g., Arduino and beyond)
- Data analysis and Scientific Computing
- Server-side and Microservices (low-footprint executables, utilizing the power of coroutines)
- Game Development
How to try
We’ve prepared two archives with compiler, samples and documentation: for Mac and iOS and for Linux and Raspberry Pi.
Check out the Github project and Release Notes for instructions.
Your feedback is very welcome in the #kotlin-native channel on our public Slack (Get your invite here.
Sébastien Deleuze says:
April 4, 2017Congrats for this promising tech preview!
Any chance you could consider WebAssembly as a supported target platform since it is supported by LLVM toolchain? IMO that would the best way for Kotlin to really matter for Frontend development in the long run.
Could you provide any guidance about what would be needed to be able to compile Kotlin code to WebAssembly via Kotlin Native?
Andrey Breslav says:
April 4, 2017I believe that we don’t have too many technical issues compiling to WASM ATM, but WASM does not really support DOM interop for now. As soon as it does, it will become a very interesting target for Kotlin
Sébastien Deleuze says:
April 4, 2017Nice, I would be happy to experiment on that topic as soon as some experimental support is available. I also think it is currently possible to have a workaround for DOM interrop by leveraging WebAssembly capability to call JavaScript functions, allowing us to experiment with Kotlin Native + webapps use case.
Jakub Błaszczyk says:
April 5, 2017Is it possible in wasm currently? how?
Sébastien Deleuze says:
April 13, 2017It should be possible using a val C++ type that is a wrapper around a JS value (as described in http://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/embind.html#using-val-to-transliterate-javascript-to-c ) + use a WebAssembly table ( https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format#WebAssembly_tables ) to import DOM methods, and then pass arguments and receive return values using Tables.
Sébastien Deleuze says:
May 1, 2017See also https://github.com/mbasso/asm-dom as a concrete example of such WASM + DOM interop example (will be updated to pure WASM without JS when supported)
exim says:
April 4, 2017What’s the use of Kotlin without Java libraries?
Christian Baune says:
April 4, 2017One language! I have seen companies using EGL for this. (EGL can be transpiled to COBOL to be run on AS400)
Nik says:
April 4, 2017you can use c/c++ libraries
eugene says:
April 4, 2017maybe, the use with C interoperability
Miguel Ángel says:
April 4, 2017You can use a C libraries and the 100% kotlin librarys.
igotti says:
April 4, 2017Take a look at the provided samples, they will show how to use native libraries easily.
obaid says:
April 4, 2017For Kotlin Native i just wana say I LOVE YOU Andrey Breslav.
Andrey Breslav says:
April 4, 2017Thanks 🙂 But I’d like the due credit to be given to the Kotlin/Native team headed by Nikolay Igotti.
Boris Chernukha says:
April 6, 2017I agree with Obaid. Compilation to native code is a big step forward for Kotlin. The rapid growth of the popularity of languages like go, rust, swift experts of the correctness of this approach. I believe that if it is possible to get rid of the VM without any special technical problems, it is desirable to do so. The choice as to the LLVM backend is in my opinion the most reasonable. Congratulations on this event and wish you much success!
Peter Holák says:
April 4, 2017So is gradle going to be the “official” build system?
Andrey Breslav says:
April 4, 2017It’s not decided whether there will be a single “official” build system. But supporting Gradle (at least among others) seems to make a lot of sense ATM.
Nat Pryce says:
April 4, 2017I hope the native compiler will work well with Make.
Andrey Breslav says:
April 4, 2017Makes perfect sense to me
soywiz says:
April 4, 2017Wow. This is just awesome. Im really interested in this. Thank you very much for releasing it.
I’m working on some pure kotlin libraries intended for games:
https://github.com/soywiz/korma
https://github.com/soywiz/korau
https://github.com/soywiz/korge
I would like to support kotlin native in those libraries. There is possible to create jar files published to maven central that works for kotlin/kotlinjs/kotlinnative?
Also. Are you accepting PRs for that projects?
Andrey Breslav says:
April 4, 2017We’ll surely review PRs for Kotlin/Native.
As for multiplatform libraries, it is work in progress, but we’ll definitely support it.
Yuri Geinish says:
April 4, 2017Any plans for the Windows compiler host/target compiler?
Andrey Breslav says:
April 4, 2017To quote the Release Notes:
Jacob A Zimmerman says:
April 10, 2017Do you know if this works with the new Ubuntu on Windows system?
Andrey Breslav says:
April 11, 2017Seems like it does, we have positive reports about this setting
Даниил Водопьян says:
April 4, 2017What advantages will Kotlin-native bring for “Data analysis and Scientific Computing”?
How is it different from porting popular DA and ML libraries from Python/R/C to JVM? AFAIK Java is already widely used as a “fast Python for servers”
Andrey Breslav says:
April 4, 2017Kotlin/Native has a) fast C interop, b) compiled language that can, for example, allow multiple threads 🙂 This makes it possible to provide a viable alternative to Python as a front-end to the same C-libraries that, for example, NumPy and SciPy are using.
Даниил Водопьян says:
April 4, 2017Or, I see! So basically, instead of bringing NumPy to JVM (like Jython couldn’t do), Kotlin-native will use their C API directly, thus reusing their GPU-optimized processing, etc. Nice!
Fernando Cassia says:
April 4, 2017There is a way to call native libs from Jython: JyNI
http://jyni.org/
Даниил Водопьян says:
April 5, 2017That looks awesome, thank you!
Adam Gibson says:
April 6, 2017Not sure what your use case is….we ported numpy to the JVM long ago:
http://nd4j.org/
At this point we’re even allowing usage from python via our new library jumpy:
http://github.com/deeplearining4j/jumpy
Multiple blas backends, cpu/gpu etc are all supported.
Даниил Водопьян says:
April 4, 2017What is the plan for porting the DA and ML libraries? Will JB do it or will it be left for the community?
Also, will those libraries be available for JVM programs via JNI (so that one could choose whether to go full native or slower native + JVM) ?
Andrey Breslav says:
April 4, 2017Nobody spoke of any plans. There’s a list of possible use cases to be considered.
Kyle Kauffman says:
April 5, 2017I’ve been working on a numpy replacement in kotlin that targets js+jvm: https://github.com/kyonifer/golem. Now that native preview is out i’ll start looking into writing a backend with direct blas access. My eventual goal is to enable writing code in kotlin that could then be deployed on all 3 platforms.
exim says:
April 4, 2017Btw, any chance you’ll add strong and weak reference distinction and get rid of [undeterministic] GC?
Andrey Breslav says:
April 4, 2017We’ll see, but nothing prevents this
Alfie Kirkpatrick says:
April 4, 2017This is quite important for embedded / IoT applications and one of the main USPs of Rust right now in our opinion. It would be great to see Kotlin alongside Rust in this space!
exim says:
April 5, 2017This would be a really killer feature… There is a big market of C++ engineers willing to consider alternatives:
Rust is ugly and unpractical
Swift is nice but locked in one platform (also on Linux, but it is somewhat half-baked)
So you have a big opportunity here. And please don’t forget that the most popular OS, including among developers, is Windows…
Erik says:
April 5, 2017Reference counting is not deterministic in any way, and I think having a full ownership system (ala rust?) would significantly change the semantics of kotlin (this is an assumption from the fact that it runs on the JVM, I don’t know the language well).
exim says:
April 4, 2017EDIT: i.e. use deterministic ref-counting….
Andrew Orobator says:
April 4, 2017Does this have any implications for Android’s NDK? Will you be able to directly call C/C++ code from Kotlin, then potentially call that Kotlin code from Java?
Andrey Breslav says:
April 4, 2017Yes, we can call C code from Kotlin, and it will likely be possible to make Kotlin/Native code callable smoothly from JVM code. See the interop description.
Lei Feng says:
April 4, 2017No love for windows :/
Tevin Jeffrey says:
April 4, 2017Does it produce a single statically compiled binary?
Andrey Breslav says:
April 4, 2017For now — yes.
A new dev says:
April 4, 2017This is fantastic news, THANKS A LOT!
One question for creating kotlin bindings for Kotlin, should i rely just on your tool to generate kotlin file, or should i do like in C# to make a C lib (OOP) ?
I’m not really experienced but i would like to learn from this
Andrey Breslav says:
April 5, 2017I’m not sure I understand the question. Please try to follow the instructions in our docs and report any issues to the tracker or slack
Andrew Grosner says:
April 4, 2017Any chance you’ll spin out some kind of Custom IDE for Cross Platform Kotlin development, or are you planning on adding iOS/Mac/etc support as a bundled plugin that Android Studio can consume and use to help build cross platform apps?
For cross platform compilation are you planning on adding compiler directives to the language so we can for example, make a library (say networking library) that calls OKHttp under the hood on Android, while on iOS use Alamofire.
Andrey Breslav says:
April 5, 2017We’ll see, both options are possible
As the blog post mentions, we are going to support this use case, yes. Most likely, it will not be through conditional compilation, but through a more modular mechanism
Andrew Grosner says:
April 4, 2017Given support for cross platform development, will there be an IDE plugin for supporting cross platform development? Such that people using Android Studio/IntelliJ can consume and begin using iOS/Mac/etc development, or will this become a new IDE?
Will Kotlin evolve to support compiler directives in this environment, so we can write platform specific code inside cross platform modules?
Will this cross platform implementation support KAPT, so we can still use it in other environments, AKA iOS development. That would be very interesting.
Andrey Breslav says:
April 5, 2017Adding to my answer above: something like
kaptis being considered, yesAndrew Grosner says:
April 5, 2017Sorry for the double reply. Once I posted I couldn’t find my questions so I thought they didn’t go through.
Sam says:
April 4, 2017Where do debugging tools fit in the roadmap? IMO this is golang’s biggest detraction at the moment.
Andrey Breslav says:
April 5, 2017We keep tooling a top priority, as always. So, debugging will come reasonably soon.
Sam C says:
April 5, 2017For now it is not possible to create a Kotlin library that can be called from obj-c/swift on iOS and from Java on Android right?
Andrey Breslav says:
April 5, 2017Not yet
Horácio Filho says:
April 5, 2017Is it already possible to consume Objective-C Runtime using Kotlin? I have not seen code examples for it.
Andrey Breslav says:
April 5, 2017We are working on it
Jakub Błaszczyk says:
April 5, 2017Interesting, but I think you should focus on polishing JavaScript target more, particularly ts2kt converter which is crucial in js based pipeline.
Andrey Breslav says:
April 5, 2017Rest assured our developers don’t have to divide attention between JS and Native. It’s two separate teams
Alexander Hultnér says:
April 5, 2017I’ve been glancing at kotlin for some time now but as a developer who doesn’t work with the JVM on a regular basis I’ve prioritized testing the grounds with Scala and Groovy.
If I will definitely keep an eye open and see if kotlin keeps gaining more traction, I’ve been a little bit worried of it being to niche.
Samuel Pastva says:
April 5, 2017Fantastic news! I am really looking forward to this for scientific computing.
Keep up the good work!
Yindong says:
April 5, 2017Will you plan to support Embedded systems/IoT device runing without OS? or some RTOS?
may be LLVM is not fit for that.
Andrey Breslav says:
April 5, 2017It’s on the table. The runtime has been designed with this use case in mind.
Sreenath N says:
April 5, 2017So Kotlin/Native is like C++ with a different syntax?
Andrew says:
April 6, 2017Besides great syntax sugar which allows you to skip lots of boilerplate code, you still would have all the other cool features of Kotlin like null-safety, in future — reflection, coroutines, and (I hope, that’s planned) great interop with JVM-based Kotlin code for Android. Also Andrey mentioned plans to work without OS — I tackled a bit with libc++-less environment and it’s a real pain — Rust managed to propose great improvements for that, I’m hoping Kotlin would be usable there too.
I’m eagerly waiting for ability to build Kotlin-based native libraries to start playing with multi-module projects — very excited with what I saw so far!
Simon Baldric says:
April 5, 2017You guys rock!!! I was about to port a PyGTK 2 application to Python/Gtk 3 and was dreaming of using Kotlin instead. Now this dream comes closer to reality. Keep up the good work!
okapies says:
April 6, 2017Is there any plan to collaborate with Scala Native? They also use LLVM and have same issue about memory management.
Andrey Breslav says:
April 6, 2017No particular plans at this time, but we are in touch with Denys Shabalin.
okapies says:
April 6, 2017Great! I long for JVM languages to sweep over the native world!
Dongqing Hu says:
April 6, 2017Great! Yesterday I was thinking about a language as replacement of Go. Now I see yours!
name says:
April 17, 2017Not a MacOS user. iOS target support from a non-MacOS host would be useful.
Andrey Breslav says:
April 23, 2017This would require some work done by Apple first, AFAIU
Ridekei says:
April 23, 2017Absolutely great job, Mr.Breslav, and the Koitlin/Native team.
I am very enthustiastic about Koitlin, Koitlin to make Android Apps… and Koitlin/Native.
I think you guys are on your way to truly make a big impact on the computer world with Koitlin.
Ummm…I am sure you’re much smarter than me but may I say two things:
I think the single most important thing that might affect the growth of Koitlin is:
DOCUMENTATION and TUTORIALS!
I know you guys are doing a good job so far, but…I think tutorials and sample code for projects can go a long way….a really long way.
For example, make tutorials using Java FX… using Koitlin and the Java FX libraries.
Make Koitlin tutorials so that many newbies can come in to the Koitlin yard, and see starting help for their next projects – Java FX/Koitlin GUI apps, Android apps, Koitlin/JS website bits.
I don’t mean to give you advice, you guys have already done great great work!
The only reason I want to say this is because, no language succeeds greatly if you need to be a really good programmer to see the beauty in it.
Besides other release complexities and delays, I think that’s why some languages fall off eventually. It’s a great language of course, but you have to be a REALLY GOOD programmer to get in and see the ‘beauty’ of it.
Please try to make tutorials and sample codes available for a variety of applications and uses. This is how you will keep winning over people daily. When they visit the Koitlin language site and see sample code – they’ll be like ‘oh, wow…let me download this and compile it on my computer.’ Soon they tweak and add their code…and then soon, you’ve won over a new believer. It’s critical to make it easy and attractive for people to ‘check out your site’, then get lured in to just try this sample code which is available…
And please focus your team on great documentation!
With abundant tutorials and documentation (well formatted, very legible), Koitlin will take over.
Easy to access and read – attractive documentation is ALWAYS a winner.
Keep up the good work, and we all want to see Koitlin grow!
Ridekei says:
April 23, 2017I want to correct myself…I was talking about a *particular language…that fell off. Because it became complex, and you somehow had to really study hard to even ‘get’ the language as a newbie. That’s the language that only good programmers could see the beauty of.
Andrey Breslav says:
April 24, 2017I totally understand your concern. And by the way contributions are welcome!
Fei says:
April 29, 2017Currently I’m using Xamarin to do cross platform app development. One thing I don’t like is its slow startup time. I wish Kotlin/Native can keep this as one of its performance goal.
Amir Abiri says:
April 30, 2017What I love about this is the potential for standalone command-line tools. This is great for devops, as distribution of script-based or VM-based tools is difficult. Having a single binary that anyone can download (or can auto-update itself) is a huge advantage. Until now the only viable option in this area was GO.