Ditto. I gave it a shot when they reached 2.0 because I liked a lot about what I saw on the surface. But no programming language will make me use IntelliJ and it’s so obvious how distasteful they regard every other environment.
Yes. I’ve only used Kotlin for Android, but the coupling with Android Studio (kind of a subset or specialized build of IntelliJ) kills it for me. I do my hobby development on an older ThinkPad with 8GB of RAM, and Android Studio is just not usable. I’d like to do most of this development in Emacs with LSP and just pull out Android Studio for wrangling gradle files and such, but there’s no official Kotlin LSP, and the unofficial ones I’ve found are incomplete/buggy/unmaintained. I like the language, but I just can’t use it.
If IntelliJ Community is significantly lighter than Android Studio, then it might be marginally usable for me. Not being able to use Emacs is a related but separate problem, I guess.
For me, null safety is still a deal breaker - glad that the Java folks are actively working on it.
It’s definitely moving in the right direction though - grateful for a bunch of recent, carefully considered language additions, to improve conciseness and correctness.
Loom is also a triumph - a real game changer for writing simple, powerful thread related code.
I had found a style of Java 17 programming that was starting to feel less verbose and had happy-enough coupling between OO and functional approaches .
And then I had a chance to code in Kotlin. Now even that streamlined style I had achieved in Java once again feels like wading waist deep in mud, especially because I can trivially arrange Java building blocks (more or less the modern Java programming experience) in Kotlin, so it’s hard to not to feel a bit grumpy about being forced by external factors to do my “Java programming in actual Java”, if that makes sense.
Another thing to note is that Kotlin can be integrated into JDK11 (and I believe JDK8 even?) without issue, which really starts to amplify the advantages Kotlin can bring.
I did this for writing a Flink application (JDK17 support is only experimental there) and it was a blast! Can’t say the same for when I’m back out of the greenfield and into the codebase my little experiment aims to compete with.
I have loved Kotlin since ~2015 and can’t imagine actually using standalone Java nowadays. Null safety is such a big deal, and Java is still lagging behind. It’s incredible when a language can make its sibling langs easier to use, like with Kotlin inferring nullability of (properly annotated) Java members.
I debated putting anything about coroutines on here. In all honesty, in my 4 years of Kotlin use, I’ve rarely used them. […] When I do need machine-local async flows, I find that I trust the standard JVM thread pools or executors more. To be fair, this has nothing to do with coroutines and everything to do with our use of Spring Boot and Spring Security at Masset.
Kotlin’s coroutines are pretty cool. I made a prototype of job system, where each job relied on awaiting on sub-jobs, and where each job is a coroutine that can be paused/resumed. Modeling this with coroutines was an interesting approach, but a thread pool is definitely fine here.
IntelliJ+Gradle is still “required” though, and this tooling lock-in will prevent adoption. And damn is Gradle frustrating sometimes.
I looooove coroutines, but the article specifically points out that this is written from the backend perspective. For server-side code I think coroutines are mostly beneficial as A) a workaround for not having OS threads on your runtime or B) state machines that use TCO, and thus not very relevant on the JVM where you do have OS threads but not TCO. Plus IIRC Kotlin’s coroutines are stackless, right? So they’re a little nerfed.
They’re stackless but the compiler generates a continuation object to store your local variables in, so at resumption it can fill all those values back on the new stack it creates. It still has the coloring limitation so suspend functions can only be called from other suspend functions, which iiuc stackful coroutines like Lua don’t have.
The tight coupling between Kotlin and IntelliJ IDEs really soured me on the language. As for why the experience is subpar outside of IntelliJ, I direct readers to this thread where you can draw your own conclusions: https://discuss.kotlinlang.org/t/any-plan-for-supporting-language-server-protocol/2471/47
I hadn’t realised this but it makes sense and it’s quite sad.
Ditto. I gave it a shot when they reached 2.0 because I liked a lot about what I saw on the surface. But no programming language will make me use IntelliJ and it’s so obvious how distasteful they regard every other environment.
Yes. I’ve only used Kotlin for Android, but the coupling with Android Studio (kind of a subset or specialized build of IntelliJ) kills it for me. I do my hobby development on an older ThinkPad with 8GB of RAM, and Android Studio is just not usable. I’d like to do most of this development in Emacs with LSP and just pull out Android Studio for wrangling gradle files and such, but there’s no official Kotlin LSP, and the unofficial ones I’ve found are incomplete/buggy/unmaintained. I like the language, but I just can’t use it.
I think Kotlin is not coupled to Android Studio specifically? IntelliJ Community should be much lighter, or at least it used to be.
It is true though that you more or less have to use IJ. But it is the best tool for the job.
If IntelliJ Community is significantly lighter than Android Studio, then it might be marginally usable for me. Not being able to use Emacs is a related but separate problem, I guess.
Is modern Java nice enough that you needn’t really bother with Kotlin anymore?
For me, null safety is still a deal breaker - glad that the Java folks are actively working on it.
It’s definitely moving in the right direction though - grateful for a bunch of recent, carefully considered language additions, to improve conciseness and correctness.
Loom is also a triumph - a real game changer for writing simple, powerful thread related code.
In my experience, no.
I had found a style of Java 17 programming that was starting to feel less verbose and had happy-enough coupling between OO and functional approaches .
And then I had a chance to code in Kotlin. Now even that streamlined style I had achieved in Java once again feels like wading waist deep in mud, especially because I can trivially arrange Java building blocks (more or less the modern Java programming experience) in Kotlin, so it’s hard to not to feel a bit grumpy about being forced by external factors to do my “Java programming in actual Java”, if that makes sense.
Another thing to note is that Kotlin can be integrated into JDK11 (and I believe JDK8 even?) without issue, which really starts to amplify the advantages Kotlin can bring.
I did this for writing a Flink application (JDK17 support is only experimental there) and it was a blast! Can’t say the same for when I’m back out of the greenfield and into the codebase my little experiment aims to compete with.
The JDK8 compatibility of Kotlin is really nice, especially when modding older minecraft versions.
Not suprising that it is compatible, since Kotlin was originally made for Android development on JDK6.
No, Kotlin was not originally made for Android development. Android-focus came later, when the language had more or less been finished.
Oh, thank you. I guess I was misinformed on that bit :p
I have loved Kotlin since ~2015 and can’t imagine actually using standalone Java nowadays. Null safety is such a big deal, and Java is still lagging behind. It’s incredible when a language can make its sibling langs easier to use, like with Kotlin inferring nullability of (properly annotated) Java members.
Kotlin’s coroutines are pretty cool. I made a prototype of job system, where each job relied on awaiting on sub-jobs, and where each job is a coroutine that can be paused/resumed. Modeling this with coroutines was an interesting approach, but a thread pool is definitely fine here.
IntelliJ+Gradle is still “required” though, and this tooling lock-in will prevent adoption. And damn is Gradle frustrating sometimes.
I looooove coroutines, but the article specifically points out that this is written from the backend perspective. For server-side code I think coroutines are mostly beneficial as A) a workaround for not having OS threads on your runtime or B) state machines that use TCO, and thus not very relevant on the JVM where you do have OS threads but not TCO. Plus IIRC Kotlin’s coroutines are stackless, right? So they’re a little nerfed.
They’re stackless but the compiler generates a continuation object to store your local variables in, so at resumption it can fill all those values back on the new stack it creates. It still has the coloring limitation so
suspendfunctions can only be called from othersuspendfunctions, which iiuc stackful coroutines like Lua don’t have.We use good old Maven with Kotlin (and IDEA).