<@U41BGS868> It's safe to say that Kotlin has been...

# kotlin-native

[louiscad]

@sksk It's safe to say that Kotlin has been a JVM-first language (although it's shifting its focus to #multiplatform). JVM currently don't support value types, but it's under design phase as part of project Valhalla. Since Kotlin tries to properly integrate into the JVM ecosystem while maintaining high-interop, the Kotlin team is waiting for the design of value types in the JVM to complete before committing to any design. Once this is done, it's likely support for other backends that can support it, like Kotlin/Native will arrive. In the meantime, Kotlin/Native has C interop, so you can probably declare structs in C and use them from Kotlin. Note that lack of value types support has not prevented a lot of great programs to be done in the JVM, the ART (Android Runtime) & Dalvik VM.

[sksk]

oh, thanks for the reply, lot of information here; i think it makes sense to wait for the JVM implementation

[sksk]

for the last point this isn't really true, most of the android games are slugish because of that specific reason, g/c is triggered really easily, and that's because people use objects rather than value type for everything

[louiscad]

@sksk That last point is not accurate. Nothing prevents you from making reusable objects (avoiding autoboxing and editing/resetting the properties), no need for value types here. This is only valid in Dalvik/ART though. In the native world, there's no gc by default, so if the game lags, it's either because it's improperly implemented, doing not really needed work, or because the device is not powerful enough, or because it's too hot and needs to throttle to not overheat, or a combination of those.