Takeaways from KotlinConf 2017

Takeaways from KotlinConf 2017(vokal.io)

69 points by robbiea 8 years ago | 25 comments

mwcampbell 8 years ago |

Kotlin Native is exciting. But there's another way to run JVM languages, including Kotlin, on iOS: the open-source Multi OS Engine (https://multi-os-engine.org/), which basically brings ART (the Android Runtime) to iOS. Note: It doesn't bring the Android UI toolkit, or any cross-platform toolkit, to iOS, so you have to write UI code for iOS. But I think that's as it should be.

Of course, there's a trade-off between Kotlin Native and Multi OS Engine. Kotlin Native is a lighter runtime. BUt with MOE, you can use arbitrary libraries that target the JVM (well, the JVM subset that works on Android). So MOE makes a lot more existing code available for iOS. For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop.

This space is going to be interesting to watch over the next little while.

hota_mazi 8 years ago | |

The Multi-OS engine has a much narrower scope than you describe: really just write apps on Android and run them on iOS.

It's not a way to run a JVM language and certainly not a way to generate Kotlin code for native targets.

Kotlin Native is very exciting because it's a potential threat across the board: not just to run iOS apps written in Kotlin, but also to generate native code from Kotlin in back end system, a domain that's currently heavily contested by both Go and Rust, and also to write Kotlin and generate Web Assembly.

It's going to be a very interesting next lustrum.

kodablah 8 years ago | |

> For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop.

Or someone writes a bridge between native Kotlin code and AOT'd JVM code. Or someone writes a kind of reverse compiler from JVM bytecode to Kotlin. Not sure how practical either is due to sheer JRE stdlib size.

peoplewindow 8 years ago | | |

Look at SubstrateVM. It's capable of making fully stripped AOT compiled binaries with a bundled JVM that only use the parts of the JRE library that are needed. Sort of like what Go can do.

krat0sprakhar 8 years ago |

> The organizers developed conference apps for both iOS and Android using Kotlin. They also built the API in Kotlin using Ktor, a framework for building server-side business logic with Kotlin.

This is really cool! Excited to dig into their repo: https://github.com/jetbrains/kotlinconf-app

blueprint 8 years ago |

Looking forward to hearing more about Kotlin/Native. We need a proper solution for this problem.

kodablah 8 years ago | |

I've done some work with it just recently. Happy to answer any questions, though I am not an expert. Overall, I think it fits very well in the Swift space and the tooling is clean. I wrote a sample DLL in it yesterday to become more familiar with it and work through some of the FFI challenges [0]. I have found it much easier to use than Scala Native (especially if you're a Windows person).

0 - https://github.com/cretz/kotlin-native-sample-agent/

gman83 8 years ago | |

I think Kotlin/Native's approach of sharing business logic while keeping the UI stuff native is probably the right choice. Although something like Flutter which render's all their own widgets is interesting because it allows you to share even more code. The question there is whether they'll be able to truly match the native widgets and have all the accessibility stuff working.

In any case it's good that different projects are approaching this from different angles.

TylerE 8 years ago | | |

History says no.

Any widget toolkit, on any platform ever, that has tried to provide it's own cross-platform widgets, has been completely terrible and ends up being native-nowhere instead of native-everywhere.

crispinb 8 years ago | | |

I'd love to see a React Native style kotlin library to enable cross-platform UI choreography using native widgets. Having done some RN stuff lately, the prospect of going back to go back to Activities and view controllers seems very dreary (I'm with Andy Matuschak on the superiority of the React model). Ditching the whole javascript toolchain for kotlin, gradle et al, while keeping components and UI-as-function-of-state, would be very appealing. I wish I had the chops to create such a library myself.

pjmlp 8 years ago | | |

That is what I do with C++ for sharing business logic.

Only need the SDK tooling, without being forced to debug extra layers of third party tools.

Using extra, non official language X usually overshadows the extra debugging and configuration efforts of adding yet another layer into the overall architecture.