With <Kotlin 2.0 being announced>, I wonder how th...
# getting-started
l
With Kotlin 2.0 being announced, I wonder how the major version will impact backwards compatibility with earlier Kotlin versions. The Kotlin evolution page does not explicitly mention anything about major versions.
Some context: We are developing a library and try to (have to?) give customers as much flexibility as possible when it comes to language versions and are worried that the major version change might be a bit of a hurdle in that sense.
v
It is not talking about minor versions either, is it? It just talks about previous and next versions, so I'd assume the same rules apply.
l
Thanks for your response, the mention
feature release
release which is the minor version for Kotlin I think. But I really hope you are right. 🙂
s
the article you linked has a "Will it break my code section?"-section Isn't that the answer you're looking for?
👁️ 1
l
Not sure, it does not explicitly mention binary compatibility which could very well be a problem when the compiler changes I think. 🤔
s
The best sentence is probably "We are committed to minimizing the impact of migrating your code from Kotlin 1.9 to Kotlin 2.0.", so I expect it to be a change like between any other versions. To me it feels like the 2.0 major version shift seems more of a (sensible) marketing push to tell people "Kotlin is faster now" (around 2.3x faster) and "Kotlin is going to develop (gain new features) faster from here on out" than to mean the language that is compiled has changed.
d
We are not expecting changes which may break binary compatibility
l
🎉 Thanks for all your input. Looking forward to 2.0. K
c
Kotlin is going to develop (gain new features) faster from here on out
This is wild to me. Between coroutines, compose, etc, Kotlin is already the fastest developping language I know.
K 5
swift 1
s
so here you can find the most requested features: https://blog.jetbrains.com/kotlin/2021/12/kotlin-features-survey-2021-results/#Themostwantedfeatures I voted for nr1 (multicatch and union types) and nr5 (having a different public than private type) and am a bit "do we really need this??" about all the others 😅
c
I am waiting very eagerly for context receivers. They're only experimental and the community have already used them to create amazing things. Unions would be a nice to have, though I managed just fine without them. I thought for a long time multicatch would be important, but then I started to follow Roman's post on idiomatic failure handling, and I don't have try-catchs anymore in the app, except at the highest part of the code (do we really need a language feature for 3 lines written once?). I think named-based destructuring is important because currently adding a field to a data class is a breaking change. Everything else 🤷‍♂️
👍 1