Few month ago someone mentioned that you were work...

# kotlin-native

[sksk]

Few month ago someone mentioned that you were working on a single compiler for all platforms (i don't remember what it was exactly), wich would result in improved build time, is there progress on this? if so where can i follow the development?

[msink]

AFAIK Kotlin/Native already use new compiler infrastructure, JVM and JS will migrate to it later.
But why it should improve build time?

[sksk]

I don't know, that's what the comment mentioned (improved build time)

[thevery]

Well, kotlin/jvm is already fast as hell on android, though KN 0.8 is not so :(

[msink]

So android will slowdown :)

[napperley]

Do know from experience that Kotlin JS and Kotlin JVM programs (don't know about Kotlin Android) compile significantly quicker than Kotlin Native programs.

[gildor]

Kotlin/JVM == Kotlin/Android, no difference in compilation time, there are additional steps made by Android plugin to sign and pack the app, but it's small part of the build time

[thevery]

Kotlin/Android is usually much slower than Kotlin/JVM because of extra steps (dex, packaging) and broken incremental because of annotation processors

[gildor]

But it’s nothing like “Kotlin/Android”, there is kotlin-android plugin, but just to integrate Kotlin build to Android Gradle plugin

[gildor]

You have “broken incremental” with any annotation processor for pure Kotlin/JVM too, no difference there, it’s not depend on Android (yeah, AP used on Android more often, but it’s the same technology as on JVM)

[gildor]

Yes, I mentioned this.
There are additional steps, but we talking about compilation, additional steps not really depend to Kotlin or Java
Also now dexing is pretty fast, even support incremental compilation and on practice much-much faster than compilation, about 10-15 times faster, not like a couple years ago when dexing was slower than compilation

[sksk]

I meant for native, JVM compilation is already good enough

[sksk]

any info on this? there is an open issue on github about slow compile time wich is completely ignored

[gildor]

Info about what? It’s always priority problem, you add features then you tune performance

[sksk]

About the progress on what's being done to adress this issue

[gildor]

There is issue, add your use cases, measurement

[sksk]

As my project becomes heavy, compile time starts to become really counter productive

[gildor]

It’s not a single issue, it cannot be just solved, it’s big permanent task

[gildor]

that usually has not so big priority for project that still on preview stage and where you add new features each minor release

[gildor]

I think the best thing which you can do is report your problem with info about project and measurements

[gildor]

I don’t think that K/N team ignores this, I’m pretty sure they have some plan and probably even possible solutions for known bottlenecks.
Don’t forget project still on preview stage, not even beta

[napperley]

K/N is getting close to the beta stage though.

[sksk]

it’s big permanent task

It became a "big permanent task", i believe if it was taken care of early in development it wouldn't be an issue, many new languages, compile quite fast
If you take Jai lang, it compile fast since the beginning, same for D
That's not something that should be "fixed" after release, if they care about speed, it should be fast
Same for value types, and that's something i don't really understand, sometime they want to keep with Kotlin JVM features and sometimes they completely ignore features and implement something completely different (Workers/Freezing API)
I keep ask all that stuff because i think it matters a lot for the adoption of kotlin native, and since it's early in development, i'd rather be sure i make the right choice for my project, i wouldn't want to depend on a slow language

[gildor]

Not sure about D, but according to Wikipedia D reached 1.0 release in 6 years and 11 years from 1.p until today, sounds like very mature
I don't want to say that "it should be fixed after release", just that on current stage there are so many different pain points

[gildor]

About value types and concurrency is just pragmatic approach, many reasons why such decisions made

[sksk]

Well D they had to design the language / compiler from scratch etc, kotlin already exist and they use LLVM; anyways, concerning value type i doubt having to do that is "pragmatic"

https://i.imgur.com/6iD9l9B.png▾

[sksk]

(i wrote the message days ago but i forgot to send it, i'm slack noob sorry!)

[sksk]

what jetbrains actually think about value type, will they implement it ? that's what i want to know

[thevery]

@sksk have you seen inline classes?

[sksk]

yeah but this hack is limited to only 1 field, wich doesn't help

[sksk]

my use case is vector math and passing structs to C directly, helpfull for opengl

[gildor]

But Kotlin is not D. Kotlin supports multiple platforms and biggest one, JVM, doesn't have value types yet. And it would be not very wise to introduce them now for one platform and get incompatibility with Project Valhalla in the Future