Earlier quoted context omitted.
I meant KMM (Kotlin Mobile multi-platform). Not aware of write once and run twice (iOS and Android) apps in these languages. Jetbrains recently removed working Linux support for KMM as a host platform.
Neither does KMM, as it only allows for business logic and Kotlin/Native has an incompatible memory model with the JVM ecosystem, requiring code to be explicitly written for Kotlin/Native.
The Kotlin Foundation
231–236 of 236 posts
Re: The Kotlin Foundation
#232Earlier quoted context omitted.
Neither does KMM, as it only allows for business logic and Kotlin/Native has an incompatible memory model with the JVM ecosystem, requiring code to be explicitly written for Kotlin/Native.
Both iOS and Android use garbage collected memory. It's just that iOS uses simpler garbage collection in the form of ARC. KMM code runs fine on JVM right? If you start from JVM code, yeah it needs to be rewritten, but that's not the premise.
https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memo...
Re: The Kotlin Foundation
#233Interesting to watch Kotlin develop. It came in and filled the niche that i always thought Scala would fill. I’ve been doing mostly Swift for the past several years, and i love it. Scala 3 looks interesting but it seems to be moving slowly. I look forward to having another Java option if I ever get back to that platform. Java was cool in 1998 but after Swift, I’ll need something nicer on the JVM
I like Scala but it's pretty complicated. I'm hoping Kotlin might be just approachable enough for the masses that we can drop the boilerplate that Java still requires.
Java is already taking hints from Scala and quickly adding Scala inspired features, which is making it similar to Kotlin. I think unless Kotlin innovates and does something not already in Scala, it will likely run into the issue of being too similar to Java ~20.
Re: The Kotlin Foundation
#234Earlier quoted context omitted.
> How did Java (as opposed to JVM) Well that’s the point - they solved it in the JVM not as a kludge of bytecode.
Well, once that happened Kotlin also gets the solution. It's rude and unfair to call out a language as "solving the problems with kludges" when they literally could not have done anything better.
Re: The Kotlin Foundation
#235Earlier quoted context omitted.
"As opposed to JVM" You don't have to convince me that green threads are far superior to async-await - I already believe that. But that's not something Kotlin (nor Java, on the language level) could have solved.
You're correct but you're forgetting that the jvm IS java. When it isn't trivial to solve at the language level they have the power to change the runtime.
Kotlin could be stuck here with a inferior co-routine model; Handicap of a headstart. Tough of course time will have to tell if the model Loom introduces in Java is going to be as great as it sounds.
Re: The Kotlin Foundation
#236Earlier quoted context omitted.
Clojure exists outside the JVM as well (ClojureScript, Babashka, ClojureCLR)
It does, but not in the same platform-antagonistic way. Clojure instead embraces many different platforms and runs on them through various dialects; Kotlin wants to become a platform.