<https://snyk.io/blog/kotlin-overtakes-scala-and-c...
# feed
e
it was just a matter of time
now we have to catch Java 😛
j
will it be difficult? I have the impression that overtaking java is like overtaking Cobol in the banking industry 😄... Kotlin is so awsome, so I am confident
b
We will need adoption beyond Android… And this is not yet clear…
👍 1
also 2000 answers only and no discussion on how they represent developers as a whole, I would be really careful with such reports
👍 1
(don't get me wrong I'm happy to see Kotlin high on charts)
s
Yeah from that report, on sever side java is still used by 86% of users and with all these new changes it will be very difficult for Kotlin to catch up on server side.
j
@suresh what changes?
s
Dont get me wrong, i love kotlin and would like to see more adoption on server side. But the new Java/JVM feature in pipeline are so good
1. Local variable type inference (
var
) 2. Raw string literals 3. records (similar to data classes) 4. Full pattern matching (even better than current scala) 5. Real value types (inline classes, hige perf improvments) 6. Virtual threads (IMO, better than Kotlin coroutines as we we dont need to think about async anymore) 7. Better native interop (no JNI madness)
Many of these features are already delivered or in preview features
One good thing is, Kotlin will also get those improvements on JVM.
j
“pattern matching better than scala” 😳?? I cannot believe it. I am still jdk 8. I seriously need updates
s
Yeah once it completed..probably in few releases 🙂 Records (data classes) are part of that initiative.
j
Thanks for the info. I was at Fosdem that day but in llvm room :-)
b
records aren't exactly data classes but yeah
s
Cool..a lot of interesting talks on JVM tracks.
b
java is moving really fast now, it also helped that they modularized things and are not afraid to break things
anyway people would stagnate with years old versions, so it made no sense to hold back people that could get new versions
s
yeah records are immutable data aggregates (means can’t use var) also no copy methods
b
it also mean that two records with the same data are the same thing
(so it would save memory for those cases)
kind of sets
s
No records are classes. There will be two objects in heap similar to data classes
👍 1
not pointing to same object in heap
c
Bit weird though, I was under the impression that Groovy was the #2 language (mostly because of Gradle build files though, I don't think many people start new projects or write actual Groovy code these days). At any rate, that's great news.
b
good to know suresh
c
tooling performance is reaaaally holding back Kotlin. Working in large Kotlin projects is such a pain 😞
2
b
what part are you talking about? building?
c
writing. IntelliJ really struggles in large projects
b
mostly for my curiosity here, I never worked on really large projects, how big are you talking about?
c
1232 files 41872 loc (not counting comments and blank lines)
This is not a really large project, it's just on the larger side...
s
According to the Kotlin conf keynote, we can expect some good perf improvements in 1.4
c
IntelliJ is feeling snappy with another project I work on which is in java and is a couple orders of magnitude larger: about 100 times larger in fact.
s
yeah java + maven is snappy. Another main pain point is kotlin DSL. It still no where in speed compared to maven.
c
the java project is also on gradle in our case, build-scripts are half groovy / half kotlin-dsl I'm not talking about build performance, I'm talking about editor performance unfortunately.
s
Good to know.
c
regarding the keynote, yes I was relieved to hear that too, but till then we'll have to suffer, or just not use Kotlin [for larger projects]
I'm really curious how JB themselves deal with this problem, with Space written completely in Kotlin and half of IntelliJ itself.
I mean when one has to wait for autocomplete for several seconds...
I noticed a new pattern in my coding: I started to sometimes write code like normal text, from left-to-right top-down, without autocomplete or jumping around, then wait several seconds for IJ to catch-up and highlight errors if any, fix, then continue, then some refactoring (via copy paste, multi-cursor and replace, because cosmos save me from using a built-in refactoring in Kotlin, renaming a constructor param or changing a signature can take 10-20 seconds).
extract variable and extract method tend to either not work at all, or do weird unintended stuff, same as inlining (I'm talking about once favourite trio: Alt+Ctrl+V, Alt+Ctrl+M, Alt+Ctrl+N)
b
are you using the new type inference system?
c
No, I did try it for a bit, but it was inconsistent with the compiler, so I had to disable after poking around some. I've also read that it's probably slower than the current one at the moment. Didn't notice performance difference myself though.