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.
Pingback: Kotlin/Native Tech Preview: Kotlin without a VM | Ace Infoway
Congrats 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?
I 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
Nice, 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.
Is it possible in wasm currently? how?
It 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.
See 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)
What’s the use of Kotlin without Java libraries?
One language! I have seen companies using EGL for this. (EGL can be transpiled to COBOL to be run on AS400)
you can use c/c++ libraries
maybe, the use with C interoperability
You can use a C libraries and the 100% kotlin librarys.
Take a look at the provided samples, they will show how to use native libraries easily.
Pingback: Kotlin/Native Tech Preview: Kotlin without a VM | Kotlin Blog/話題/ノマドアンテナ
For Kotlin Native i just wana say I LOVE YOU Andrey Breslav.
Thanks
But I’d like the due credit to be given to the Kotlin/Native team headed by Nikolay Igotti.
I 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!
So is gradle going to be the “official” build system?
It’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.
I hope the native compiler will work well with Make.
Makes perfect sense to me
Wow. 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?
We’ll surely review PRs for Kotlin/Native.
As for multiplatform libraries, it is work in progress, but we’ll definitely support it.
Any plans for the Windows compiler host/target compiler?
To quote the Release Notes:
Do you know if this works with the new Ubuntu on Windows system?
Seems like it does, we have positive reports about this setting
What 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”
Kotlin/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.
Or, 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!
There is a way to call native libs from Jython: JyNI
http://jyni.org/
That looks awesome, thank you!
Not 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.
What 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) ?
Nobody spoke of any plans. There’s a list of possible use cases to be considered.
I’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.
Btw, any chance you’ll add strong and weak reference distinction and get rid of [undeterministic] GC?
We’ll see, but nothing prevents this
This 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!
This 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…
Reference 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).
EDIT: i.e. use deterministic ref-counting….
Does 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?
Yes, 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.
No love for windows :/
Does it produce a single statically compiled binary?
For now — yes.
Pingback: Kotlin/Native Tech Preview: Kotlin without a VM | ExtendTree
This 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
I’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
Any 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.
We’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
Pingback: Kotlin compiles directly to native code via LLVM – Miller Trades
Given 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.
Adding to my answer above: something like
kaptis being considered, yesSorry for the double reply. Once I posted I couldn’t find my questions so I thought they didn’t go through.
Where do debugging tools fit in the roadmap? IMO this is golang’s biggest detraction at the moment.
We keep tooling a top priority, as always. So, debugging will come reasonably soon.
Pingback: Kotlin/Native, Infragistics Ultimate UI for Xamarin, ActivePython 2.7.13 and 3.5.3, and Progress OpenEdge 11.7 — SD Times news digest: April 4, 2017 - Khabri No 1
For 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?
Not yet
Pingback: Kotlin compiles directly to native code via LLVM - The Gizmo Effect
Pingback: Kotlin/Native, Infragistics Ultimate UI for Xamarin, ActivePython 2.7.13 and 3.5.3, and Progress OpenEdge 11.7 – SD Times news digest: April 4, 2017 – Ok Huge
Pingback: Kotlin compiles directly to native code via LLVM |
Is it already possible to consume Objective-C Runtime using Kotlin? I have not seen code examples for it.
We are working on it
Interesting, but I think you should focus on polishing JavaScript target more, particularly ts2kt converter which is crucial in js based pipeline.
Rest assured our developers don’t have to divide attention between JS and Native. It’s two separate teams
Pingback: Kotlin compiles directly to native code via LLVM | Subremes Codes
I’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.
Fantastic news! I am really looking forward to this for scientific computing.
Keep up the good work!
Will you plan to support Embedded systems/IoT device runing without OS? or some RTOS?
may be LLVM is not fit for that.
It’s on the table. The runtime has been designed with this use case in mind.
So Kotlin/Native is like C++ with a different syntax?
Besides 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!
You 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!
Pingback: From Kotlin to Java: moving back seeing all the flaws – NamekDev
Is there any plan to collaborate with Scala Native? They also use LLVM and have same issue about memory management.
No particular plans at this time, but we are in touch with Denys Shabalin.
Great! I long for JVM languages to sweep over the native world!
Great! Yesterday I was thinking about a language as replacement of Go. Now I see yours!
Pingback: Bookmarks for April 5th through April 6th | Chris's Digital Detritus
Pingback: JetBrains Releases Tech Preview of VM-less Kotlin — ADTmag | US-China News
Pingback: Revue de Presse Xebia | Blog Xebia - Cabinet de conseil IT
Not a MacOS user. iOS target support from a non-MacOS host would be useful.
This would require some work done by Apple first, AFAIU
Absolutely 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!
I 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.
I totally understand your concern. And by the way contributions are welcome!
Currently 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.
What 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.
Pingback: 不使用虚拟机的 Kotlin | 神刀安全网