<@U3SK5B492> In response to someone else, you ment...

# kotlin-native

[spierce7]

@olonho In response to someone else, you mentioned some things that I wanted to follow up on.

You mentioned some improvements that need to be worked on with k/n: using the technology in combination with Gradle. When you integrate with Gradle, will that be when we finally get incremental compilations?

You mentioned that Kotlin 1.3 features need to be added before a stable release as well. Is there a place where I can read about the changes coming in Kotlin 1.3? I haven't been able to find a roadmap or anything for Kotlin 1.3.

You mentioned that k/n already shares a code base with jvm and js compilers. Getting the compilers under the same arch and sharing an api is one of the first steps to a public API to 3rd party Kotlin compiler plugins (probably the feature I've been most anticipating). How close are we to that as a reality?

[gildor]

You can check slides from talk by Stanislav Erokhin from Kotlin team
https://photos.app.goo.gl/aAL1UuCYLYPqBpoS7

Also there is KEEP about inline classes, which can be used to implement unsigned arithmetics without performance penalty
https://github.com/Kotlin/KEEP/pull/103

[gildor]

Anyway there are some issue on Kotlin issue tracker that target 1.3 milestone 1, so I suppose we will get official announcement, maybe on Kotlin Conf, maybe even earlier

[gildor]

shares a code base with jvm and js compilers.

Check slides, looks that 1.3 will have experimental IR backend shared for different targets

[spierce7]

Wow, thanks for the slides. Really awesome stuff. I'm excited about contracts. I also saw that IR stuff. They mention it as a "replacement" for annotation processors, which means it's what I've been waiting for. What does IR stand for?

[olonho]

IR is intermediate representation, compiler data structure describing source code in a way making codegeneration and code transformations easier

[olonho]

1.3 will be a first release where at least JS and Native (and maybe JVM) will have IR-based architecture, so not only a compiler frontend, but also significant number of code transformations are shared, thus public plugin API can work in terms of IR

[olonho]

incremental compilation in the new library format will be not exactly what you would think of it, as in closed world final aftifact reuse is not so easy, but compilation speedup shall take place

[drofwarcs]

@spierce7 if you're interested in reading more about IR checkout section 11.3 of this article https://www.aosabook.org/en/llvm.html

[olonho]

nope, that article about LLVM IR, while this one is Kotlin compiler IR

[spierce7]

Yeah, I'd really only care about Kotlin IR. I appreciate the thought though. Thanks!

[drofwarcs]

Ahhhh...good point.

[napperley]

Do wonder if Kotlin JS at a later point (in the future) will merge into Kotlin Native via the WASM side.

[gildor]

I highly doubt it.
Wasm is on early stage. To replace JS you need easy access to browser APIs, smooth interop with JS or at least some standard library. Now it's too low level .
It's like attempt to replace java with jni.

Maybe in a few years it would be possible to compete with general JS, but I don't think that without good interop with existing platform it would be possible

Also, it wouldn't be "merge" of Kotlin JS rather "drop of support", and I don't think that it would be good decision for Kotlin mpp ecosystem

[christophsturm]

is there a timeframe for 1.3?

[gildor]

As usual no official ETA