:mega: :mega: Here at JetBrains we are currently...

# random

[orangy]

📣 📣 Here at JetBrains we are currently looking at slightly longer perspective regarding Kotlin evolution, and on one topic we decided to ask you. The question is: “What do you expect from Kotlin 2.0?“. Note, that it doesn’t mean we are planning v2, or preparing breaking changes, or anything at all. It’s about setting expectations right and understanding that we (Kotlin Team) and you (our valuable community) understand things similarly. So if you can think for a while and write down few sentences about the topic we would be grateful. Thanks! (posted in #C09222272 on purpose, please don’t repost)

[tmg]

Less features, more simplicity.
Don't become another C++/Scala that has every other feature in the world. Things can be simple, elegant and powerful, but kotlin seems to like having a ton of keywords functionality.

[orangy]

@gildor what’s so scary? 😄

[zokipirlo]

Not so much about Kotlin 2.0 but I wish if you could do something to JNI that you did to Java. I mean to simplify communication between native code and Kotlin 😇

[orangy]

@zokipirlo You could submit an issue to kotl.in/issue if you have a specific request. This question is about something different 🙂

[mzgreen]

More powerful extensions, like in Swift where you can make some arbitrary class to implement your interface.

[mzgreen]

Interface composition like:

typealias ComposedType = InterfaceFoo & InterfaceBar

[hho]

This is really difficult.

As a developer on the JVM, I'd expect some fundamental cleanups in a version 2. Fixing the issues that couldn't be done without breaking things. Like overriding Java properties (possibly changing semantics) or JVM default methods in interfaces (possibly breaking binary compatibility).

In a general direction, I'd like to see less special cases and more regularity (e.g. I don't care if there'll be collection literals or not – but I don't like to have a special array syntax only for annotations).

Given that 2.0 is probably far away, I'd also put future JVM developments like fibers and value types on the list: Use these instead of reimplementing them (avoiding issues like with @JvmDefault).

[Dominaezzz]

Closeable Sequences. Like in C#.

[Dominaezzz]

Multidimensional arrays!! At least nicer syntax lol. I guess this could be a 1.* thing.

[gildor]

what’s so scary? 😄

@ilya.gorbunov If we now have talks about this topic it means that 2.0 is probably closer that we (community) or maybe even Kotlin Team think 😃

[gildor]

My wish is to be up-to-date with new Java and JVM features and if some require backward incompatible changes do that in 2.0

[orangy]

@gildor nope 🙂 at least we don’t have any plans like this, but when postponing things we need to decide if we have to postpone it till 2.0 or can do something in 1.x.

[Jakub Gwóźdź]

I'd vote for CLR/.Net backend.

When creating windows desktop apps, I guess WinAPI could be used but... it's all but simple or elegant.

OTOH I love tornadoFX and stuff, but it requires customer to have jre etc... nah, for small windows apps, java output is not ideal neither.

[gildor]

With JEP 200 (modular jvm) and JEP 343 (packaging tool) it should be so bad to have self-contained java apps now

[Jakub Gwóźdź]

@gildor still it's a) not native to the system (I'll do some performance tests on warmup time and memory usage soon) and b) can't interop with .net libraries etc.
I'm not saying that we're doomed without CRL, but that I'd really like to have the possibility to use Kotlin there as well.

[cbruegg]

Honestly, the language feature set itself seems more than sufficient to me already. I'd suggest putting a strong focus on libraries for working with I/O, dates and times, etc. Basically minimize the need for JDK-Stdlib imports, which in turn would make it easier to write multiplatform code without tons of expect/actual pairs.

[cbruegg]

Apart from that, I'd say look into supporting Fuchsia, if that's where Google's mobile development is heading. I suppose Kotlin/Native could be helpful here, so again a good multiplatform library situation would help, as well as maturing Kotlin/Native tooling.

[gildor]

Support non-existent OS with 0 users and 0 devices, unknown runtime, API and not clear targeting and license? It's even more premature than feature list for non-existent plan for Kotlin 2.0 😅

[gildor]

@Jakub Gwóźdź a) not native in terms of what? b) but can interop with Java libraries

[dalexander]

The only breaking change on my wishlist for Kotlin is closed-by-default going away, but that’s a decision that seems unlikely to change. Otherwise I’d like to see language support for partial application for method and class parameters and their type parameters (nice to have), union types (might happen), typeclasses (apparently possibly on the radar for the distant future).

[cbruegg]

@gildor Fair point. But maybe keep an eye on it 😉

[kenkyee]

Maybe make the array syntax nicer for the data science folks.
Ditto support for later Java versions.
Oddly enough, I can't think of much in Kotlin language features I'd really want that isn't being addressed already...kotlinx serialization already addresses json support for classes natively (like Swift's Codable).
Make things (code completion and compilation and kapt) faster and stack traces in coroutines better would be nice but that seems like a 1.x thing. Ditto support for GraalVM but that's addressed with K/N.

[Sam]

I’d add love to have the following features included in 2.0:
1. Support for targeting Dart VM to make it possible to implement UI with Flutter using Kotlin
2. Multiple return ability like in Scala, Python, etc

[poohbar]

I expect:
1. Removal of features that are not that useful. (Interface delegation?)
2. Significant clean up of existing features that are not ideally implemented due to backward compatibility reasons.
3. Maybe static methods?
4. More powerful data classes
5. Truly immutable collections
6. Clean up of the standard library with regards to more consistent function names.

Please resist listening to the small but vocal minority that can't rest until Kotlin becomes another Scala. No, we don't need pattern matching. No we don't need type classes. Just KISS.

[Dominaezzz]

@poohbar What's wrong with type classes?

[poohbar]

@Dominaezzz I just don't think it's a pragmatic choice. I wouldn't want work on a project that uses type classes.

[Daniel]

My opinion: Keep it simple, keep it clean, make everything as performant as possible. Also invest even more in tooling and build useful libraries around kotlin. (for example an official static source code analysation lib).

I think you can do everything currently with kotlin and that very elegant. Also the tooling support already sets it apart from other languages and if you continue to invest in this kotlin is truely special

[pavel]

I would expect v2 to have some breaking changes. I think the only one I want is to go from public by default to internal by default. Otherwise I am pretty happy. Union types would be nice, but that can be done in 1.x

[jdiaz]

@poohbar I actually use interface delegation and think it's pretty cool

[napperley]

There is a common pattern emerging from the discussion with many Kotliners wanting to see more done with tooling, and expanding the Kotlin ecosystem (more libs). More attention needs to be paid to the use of Kotlin in development areas other than mobile. Kotlin WASM support needs to be expanded (eg create a library that covers web front-end development which isn't reliant on a JS framework).

[pavel]

@napperley there is very significant attention being paid to use of K on the backend

[jmfayard]

Kotlin 2.0 is the tipping point when people realize we don't need to write JavaScript anymore

[thomasnield]

More idiomatic math API, especially for continuous (double/float) types and ranges. https://github.com/thomasnield/KEEP/blob/master/proposals/stdlib/exclusive-ranges.md

[Jacob Applin]

@poohbar Interface delegation is awesome, I use it all the time.

[poohbar]

@Jacob Applin you shouldnt

[Jacob Applin]

Why?

[aarjav]

Kotlin 2.0 should deprecate or change any feature which is either being used incorrectly most of the time or preventing use of another common feature because of some edge case. The deprecated feature then should be removed in 3.0. Honestly I don't know if there are any such features (lateinit came up a few times in Kotlin conf closing panel least favorite feature question), however I would like Kotlin to not suffer for the sake of backwards compatibility.

As for additions, contracts (that don't feel like boilerplate) and anything that would help in designing DSLs (allow overriding some of & | << or >> operators. Infix for multi parameter fun)

[josephivie]

Probably controversial opinion time:
Concurrency stuff from Kotlin Native should be delayed from Kotlin 1 to Kotlin 2, where it should be introduced to the entire ecosystem with keywords and design that make you think about it when you use concurrency. I, for one, would propose that a type suffix (like ?) be created to describe whether or not the object is frozen. This kind of state really should be reflected in the type, because it breaks stuff in the same way null does.

[gaetan]

IMHO, today kotlin is “code with pleasure” but not “develop with pleasure.” What I mean is that we have a great language, that we love, but the developer experience is not that good. I sometimes have the feeling to always be in a beta version for the tooling. For example, there is a new functionality (like MPP) but it’s not compatible with another part of the tooling (gradle build in kotlin).
So my wish would be to slow down on features and put more effort on the tootling. We should be on par with all platform tools where kotlin can be run. That means : better compilation performance, hot reload everywhere, …

[poohbar]

@gaetan I must agree with this. I actually thought it wouldn't bother me that much however at work our project is mostly Java with bits of Kotlin and it's very clear that Java is still the first class citizen in IntelliJ. It is faster and way more stable experience to work on Java project compared to Kotlin. I guess this will naturally improve with time. I am also not too excited about the slower compile times of Kotlin compared to Java and that will probably never be fully remedied.

[jmfayard]

To be fair, Kotlin native and Gradle Kotlin DSL were very much bleeding edge until not long ago. I agree about the inconvenience but I think both of them will advance the needle significantly. It's not a "let's invent a new JS framework" thing.

[jdiaz]

About kotlin 2 I would like to see something like coroutines but for distributed things. So you don't have to think about where the things are, that's taken care of for you

[kenkyee]

MPP IS pre-release...actually not even beta because it's at version 0.xxx

[thelgis]

My personal wish list is: 1) Truly immutable collections, 2) Channels going out of experimental state, 3) distributed Actors

[ursus]

im not happy about bitwise operators, and not having static factory functions and having to create companion object instance instead

[ursus]

and I also want lazy with arguments from local scope

[gildor]

@thelgis But all 3 features are just libraries, I don’t think that you need 2.0 for that

[gildor]

and I also want lazy with arguments from local scope

imo it looks as anti-patern singleton with params. Why do you need this?

[ursus]

@gildor basically caching some synchronous calculation for example loading bitmap. Successive calls of the function if need to !! in the else branch, just ugly..

[gildor]

You don’t need lazy for that also just use coroutines and Deferred

[ursus]

hmm neverheard of it

[ursus]

oh cooroutines, nah, its synchronous code

[ursus]

val _bitmap = if bitmap == null loadBitmap(some param) else bitmap!!

[ursus]

omg you can elvis that, been doing it dumb like that for a year, thanks brain 😁

[gildor]

Successive calls of the function if need to !! in the else branch, just ugly..

This has nothing with lazy and you don’t need !!
Also it becoming offtopic for this thread

[ursus]

why, lazy caches the operation in a property upon first call, looks like same thing to me, but nevermind elvis is fine and avoids !!

[thelgis]

@gildor you are right which makes me think that I probably find the language itself is not missing anything major. My wish list has more to do with the evolution of the ecosystem and the libs. If I had to say something about the language personally I would consider removing some of the function naming restrictions to make it easier for DSLs. But I know this is a controversial topic and that it was a design decision to prevent this kind of freedom.

[diego-gomez-olvera]

1- Enforced formatting, Go style
2- Name based destructuring. At least a warning with name mismatch.

[pavel]

Remove `companion object`s. I’ve had to do way too many code reviews with people using them instead of top level functions/values. I’ve yet to see a use case where they were needed.

[thomasnield]

Companion objects are fine imo. I extend abstract classes and interfaces on them quite a bit. Plus it's nice they can have init { } and other class/object behaviors

[pavel]

@thomasnield do you have a good example where you can’t replace them with top level stuff?

[ursus]

Im not sold on toplevel functions, sometimes theyre nice if the domain is general to language like lists, optionals, etc,, but namespacing it like Foo.createWhatever(), when Foo is my domain, is better imo

[thomasnield]

@pavel well anything is possible as long as you don't mind boilerplate on the API usage side. Companion objects allow me to call factories on the class while implementing them to an interface. I'll share an example later.

[louiscad]

I love K `companion object`s. I love how they can extend classes, implement interfaces, have operator functions. I'll protect what I love by (nearly) all means, beware! 🤨

[deviant]

collection literals
bitwise operators (&,|)
ternary operator

[gildor]

oh, exactly matches with my anti-list

[gildor]

okay I’m not so much against bitwise operators, but still has a lot of concers about current proposal

[deviant]

these 3 still make me feel kotlin isn't completed language yet. if/else instead of ?...:... feels like a dirty hack. and lack of &,| is even more weird, because we still use programming languages for ruling the machines. and bitwise operators always were first class things in any languages i know.
as for collection literals, well python and swift users dont suffer much, so why we should? 🙂

[cbruegg]

Disagreed. if-else is not a hack, it's just a logical consequence of (almost) everything being an expression.

[cbruegg]

And I feel like collection literals don't provide enough value to justify bloating the language to be honest.

[gildor]

I do not suffer without collection literals

[cbruegg]

I agree though that bitwise operators would be very useful

[gildor]

I’m not against bitwise or collection literals completely, but price for them may be too high in terms of language complexity vs gain

[louiscad]

In Kotlin 2.0, if it can't be done in 1.x, I'd like implementation delegation to be redesigned to allow delegating from a class member, and be more flexible overall (e.g. so you could delegate to an expression). Apart from this, I think Kotlin 1.3 is already awesome, I'm a huge fan, and nothing that can't be done in 1.x (tooling, libraries, language features like smart enum "import" inference & val subject in while loop, multiplatform and native new stuff) crosses my mind right now.

[littlelightcz]

Besides of improving compile times and compiler smartness I've seen some benchmarks showing that e.g. for (i in items) {} should be faster than items.forEach {}. Unless it's already like that and in case I understand the current situation right, would it be possible to implement some general Sequence chained calls expansion into imperative boilerplate for maximum performance?

[juliocbcotta]

kapt multiplatorm would be great.

[gildor]

Kapt based on Java APT tool, so I doubt about multiplatform kapt
But Kotlin team plans provide complier plugins API which may be much more powerful tool for metaprogramming

[apatrida]

Try again for the emit (hat ^) operator for the value being emitted from a lambda. It still remains the most "implied" thing about Kotlin that isn't evidently visible. The IDE hints help a bit, but they are implemented in a way that is too noisy.

[apatrida]

DSL fix for things that cause operators or functions to be used for actions that naturally want to be there without any such operator. Like the +"text" in the kotlinx.html DSL.