A modern programming language that makes developers happier.

kotlinlang

:mega: *<https://kotlinlang.org/docs/roadmap.html|KOTLIN ROADMAP UPDATE: Find out what comes next for Kotlin!>* :kodee-happy:

:hammer_and_wrench: *Language evolution*: more efficient data handling, increased abstraction, and enhanced performance with clear code.
:zap: *K2-based IntelliJ IDEA plugin*: faster code completion, improved highlighting and search, and more stable code analysis.
:globe_with_meridians: *Kotlin Multiplatform*: release direct Kotlin to Swift Export, streamlined build setup, and simplified creation of KMP libraries.
:package: *Experience of third-party ecosystem authors:* simplify development and publication process for Kotlin libraries, tools, and frameworks.

For more details, head over to our Kotlin roadmap page. Explore our accomplishments and learn about our key objectives and future plans!

:arrow_right: *<https://kotl.in/roadmap>* :arrow_left:

"Swift export" is both in New items and Deleted items - I guess they're not exactly the same items but it is a bit confusing :slightly_smiling_face:

one question regarding <https://youtrack.jetbrains.com/issue/KT-49511|Improve Kotlin scripting and experience with .gradle.kts>: does it also include improvements to stand-alone scripts like `.main.kts`? I'm asking because it's mentioned in the "Summary" section of this issue, but it's not in "Plans" section. We could really use some bugfixes there, both from the compiler and the IDE side

<@UQX3ZNU12> curious what are the bugs you're thinking about. `.main.kts` is working great for me. My main gripe is the resolver not understanding Gradle metadata but in all honesty, this cuold as well be thought as a feature

<@U79JY5TL3> for simple one-file scripts it works ok-ish, true problems start if you try to import a Kotlin file from a script, so e.g. share some piece of code across your scripts. See this <https://typesafegithub.github.io/github-workflows-kt/faq/|FAQ> for my library that is used together with Kotlin scripting, the last 3 items are devoted to the issues with Kotlin scripting, along with some hints how to work around them. There are more (<@U0152P3VB5J> reported some in the last days), but the mentioned ones are the most crucial ones from my PoV, and the users of the lib stumble upon them most frequently

Oh yes, I see :+1:  Thanks for the pointers!

Removing _context receivers_ without a practical/real-life migration path is _pita_ :disappointed_relieved:

For the Swift export, I was reading this ticket:
<https://youtrack.jetbrains.com/issue/KT-64572?_gl=1*10bk9m2*_gcl_au*MTg0ODU0MTI3NC4xNzI2MjU0OTAw*_ga*MTkzOTk5MDQwMi4xNzI2MjU0ODk4*_ga_9J976DJZ68*MTcyNjc1OTE0MC4yLjEuMTcyNjc1OTE3Mi4yOC4wLjA>.

And was curious why these are out of scope?  Can generic/data class-like behavior in Kotlin be done w/o these?

"Generics are out of scope.
Sealed/enum/data classes and data objects are out of scope"