5 ms·

Kotlin is plenty safe for now. * Android is a massive platform, and Android is basically stuck on JDK8 (or JDK11 with desugaring, wooo). * iOS compatibility-i

Kotlin is plenty safe for now. * Android is a massive platform, and Android is basically stuck on JDK8 (or JDK11 with desugaring, wooo). * iOS compatibility-ish. KMM is not ideal and mostly generates ObjC compatible objects (so generics are mostly screwed for Swift and writing iOS code is not ideal, but even being able to define common and enforced contracts is cool. iOS benefiting from projects like SQLDelight is super cool) * Jetbrains hedged their bets, and Kotlin/Multiplatform is a solid option. Coupled with Jetbrains Compose for UIs as well as having the entire Java ecosystem available is very solid. Compilation for so many platforms, directly to native executables is cool. * Java is still very slow to evolve. Kotlin has had data classes for a long time, Java recently added records. Inline classes offer some nice type safety at basically zero costs. Coroutines and structured concurrency are a beautiful way to work, and Project Loom would only build the foundations of that. Context extensions (while terrifying in the potential for spaghetti code they offer) are a useful feature, reified generics have some great potential. Now, Kotlin has its disadvantages too. Compilation times are not that great (hopefully K2 fixes this partly), but it's relatively safe and is kind of more than just a JVM language by now.)

mbStavola 4y ago
I agree with everything you said except for "Java is still very slow to evolve." New Java versions are cut every six months since 2017 and since then has added a significant amount of new features, syntactical sugar, APIs, et cetera. Not only that, but they've also have been pretty aggressive IMO in deprecating and removing legacy. Very very different than the Java I remember working in years ago.
- weego 4y ago
  You're correct of course, but to back up the parents comment, they do have a habit of implementing things other than the low hanging fruit that developers are frustrated not having, leading the drive towards other jvm langs
  - mbStavola 4y ago
    What are some examples of those low hanging fruits?
    - ohgodplsno 4y ago
      Functional/SAM interfaces (transforming interfaces with a single method into a simple lambda), pleasant usage of lambdas (last lambda parameter can be put outside of the call like(this) { ... }, leading to a language that lends itself really well to building a DSL, coroutines were not a low hanging fruit but absolutely are infinitely more pleasant to use than RxJava, operator overload including invoke(), ranges that are pleasant to use (0 .. 10).forEach { }, or when (floatVariable) { in 0.0f .. 1.0f -> ... }, pattern-ish matching with when (not quite full on functional language powerful, and I believe that Java is not only catching up to it but making their switch quite a bit better), a standard lib that is packed full of extremely useful and consistently named methods, extension functions, delegation (if you inherited a SDK that has a piss poor interface, you can simply make a SDKWrapper(val internalSdk: SDK): SDK by internalSdk, which means that it will automatically implement it, and you can then have your wrapper do whatever around it (logging, better functions, DI, etc.))) Kotlin is truly a pleasant language, both when you don't know it (although it can look a bit symbol soup-y at times for juniors), and when you fully know it.
    - origin_path 4y ago
      Just browse through the Kotlin standard library. It's basically just a set of mappings to the Java standard library with a whole lot of extension functions to make it easier to use.
- quantified 4y ago
  In HN a while back, an Oracle dev pointed out that the evolution is slow for a reason. Which confirmed slow. New releases every 6 months, but not that much in the way of changes. This isn't criticism of the fact of it or going into why it is or whether it should be that way. It's just a statement of fact.
- Alupis 4y ago
  > New Java versions are cut every six months since 2017 and since then has added a significant amount of new features And yet, the overwhelming majority of the Java community are still using JRE8 with none of these new features. There are some that love this new pace of language development, but very few are actually using new features in production code.
  - yardstick 4y ago
    The hesitancy in jumping beyond JRE8 is the large backwards compatibility road bumps in JDK9-11, and now again with 17/JavaEE->Jakarta. I wish Java would continue to add new features but be a lot more considerate of avoiding, completely, migration headaches. We are migrating Java 8 -> 17 now and it’s been a right royal pain. I’m glad we didn’t jump to 11 LTS, and instead make one big leap. It might be a very long time before we do another LTS upgrade if they keep making poor migration choices.
    - kaba0 4y ago
      The only relatively bumby migration was 8->9. After that it is a very smooth ride, and that bumpiness was the price for the accumulated tech debt/slow down from the end of the Sun era.
      - vips7L 4y ago
        8 -> 9 wasn’t that hard for me personally. For our applications it was just adding things to the build to make sure javax.xml was present. The real difficulty for us was upgrading the Play framework since the Scala community likes to make breaking changes with every release.
      - Alupis 4y ago
        Well, my understanding is (but I have yet to personally experience) the migration from 17 -> 18+ is rough because of all the javax.* packages being renamed jakarta.* Which likely means touching a pretty significant portion of your codebase for the upgrade, and then who knows what 3rd party libraries you depend on are expecting... So it may be as simple as Find/Replace for some folks, for others, it might be a deep dark rabbit hole. Not breaking things used to be Java's MO. Yes, that means a ton of legacy cruft built up over the years... but we used to be able to depend on Java to "Just Work". Perhaps some of this is necessary. After all, the C# folks seem to have no problem breaking everything to add new features... but I'd assert the Java community as a whole is much less tolerant of breaking changes and rapid deployment of features.
kaba0 4y ago
> iOS compatibility-ish I don’t know how well it works, but we have seen these kinds of projects, and they seldom work as is. Not sure how well Scala Native works, even though it predates Kotlin’s try. (Though scala.js is surprisingly good!) But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java? Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms. For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane). > Java is still very slow to evolve Is it a problem? The majority of developers don’t like running after the language, even though it may seem so based on online hype circles.
- ohgodplsno 4y ago
  >I don’t know how well it works, Well enough, provided you stay within the known bounds. Hell, some people at Touchlab even went as far as porting Jetpack Compose to work on iOS (which, uh, I would not recommend in its current state), and it technically works. I probably wouldn't recommend writing all of your app logic in Kotlin, but being able to share the data layer is amazing. >But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java? It depends on where you're looking. Most modern android development will most likely be done in Kotlin. Backend work, for things started relatively recently, Kotlin is not surprising. But mostly, Java does not make iOS compatibility a goal. Java tell you "get a JVM and run our shit" (or get GraalVM and have basically an embedded JVM). Kotlin has two sides, and Kotlin/Native does not depend on the JVM. >Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms. j2cl still brings in a light JVM to the Web. Kotlin does not. It provides interop to the JS APIs as well as its own tech, but it's not meant to take your Kotlin code and immediately run it on the web (which is an awful, awful idea). You're still meant to write your browser specific code, your android specific code, your x86 specific code, etc. In any language you want, even! Write it in Kotlin/JS, or let your typescript consume the Kotlin/JS bindings. However, you can have a common base that'll work everywhere. > For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane). Graal is an extremely cool project, but with different goals. Write once, run everywhere is a lofty goal, but it only works on very similar platforms (Windows/Linux/OSX). Kotlin has taken a Write once, specialize what is needed approach.
bitexploder 4y ago
Do languages really need new features every N months to stay relevant?
- nordsieck 4y ago
  > Do languages really need new features every N months to stay relevant? I think a fixed N month release schedule is much healthier than what Java did before, which was wait until everyone was on the bus in order to ship, which resulted in multi-year delays.
- ohgodplsno 4y ago
  Depends. Is stuff like context receivers (https://nomisrev.github.io/context-receivers/ https://nomisrev.github.io/context-receivers/) needed ? No, although it's a fun experiment. Are multiple receivers needed (https://youtrack.jetbrains.com/issue/KT-10468/Multiple-receivers-on-extension-functionsproperties https://youtrack.jetbrains.com/issue/KT-10468/Multiple-recei...) ? Not really, but when you are dealing with the JVM, nested class hell is a very common thing, and cleaning up your code is always pleasant. Implicit namespacing ? (https://youtrack.jetbrains.com/issue/KT-11968/Research-and-prototype-namespace-based-solution-for-statics-and-static-extensions https://youtrack.jetbrains.com/issue/KT-11968/Research-and-p...) Fun thing to get. The thing is, they're all optional. You're never going to use any of these features if you don't need them. Your code can stay as a nested list of calls. But put them all together, and you can have code that is super explicit about what it needs to do, without having to re-pass things that are already there.
- AnimalMuppet 4y ago
  Depends. Are the features making things better, or just more complicated? Even if it makes things better only for, say, 10% of users, but doesn't make it worse for the other 90%... the users will take that every N months for as long as the language authors can do it.
- kaba0 4y ago
  No, but fortunately Java doesn’t do that. They have long running projects, when one is nearing completion it will be put in preview in the upcoming release. No rush to make it into anything, it’s ready when it’s ready. (Which should be copied by the rest of the industry as well)
biztos 4y ago
I’m not a Kotlin user, but this struck me as ambitious: > having the entire Java ecosystem available and, in the same point: > Compilation for so many platforms, directly to native executables Does this mean you can compile pretty much any Java libraries to non-JVM executables?
- MrPowerGamerBR 4y ago
  No, if you are targeting a different platform you can't use JVM libraries. If your target is JavaScript, you can use JavaScript dependencies (sort of: they won't have any type bindings so you will need to code then yourself) but you can't use any JVM libraries on it.
- slively 4y ago
  No, if you use Kotlin native you do not get access to Java libs.
- ohgodplsno 4y ago
  As other said, yep, you do not get the Java ecosystem if your target is native executables (or JS). there are alternatives like kotlinx-datetime, kotlinx-serialization, the kotlin stdlib. However, if you know you're going to stay on a JVMable target, feel free to not use Kotlin/Multiplatform, but regular JVM Kotlin libraries
yCombLinks 4y ago
Slow to evolve and long-term backwards compatibility are selling points.

mbStavola 4y ago

I agree with everything you said except for "Java is still very slow to evolve." New Java versions are cut every six months since 2017 and since then has added a significant amount of new features, syntactical sugar, APIs, et cetera. Not only that, but they've also have been pretty aggressive IMO in deprecating and removing legacy. Very very different than the Java I remember working in years ago.

weego 4y ago
You're correct of course, but to back up the parents comment, they do have a habit of implementing things other than the low hanging fruit that developers are frustrated not having, leading the drive towards other jvm langs
- mbStavola 4y ago
  What are some examples of those low hanging fruits?
  - ohgodplsno 4y ago
    Functional/SAM interfaces (transforming interfaces with a single method into a simple lambda), pleasant usage of lambdas (last lambda parameter can be put outside of the call like(this) { ... }, leading to a language that lends itself really well to building a DSL, coroutines were not a low hanging fruit but absolutely are infinitely more pleasant to use than RxJava, operator overload including invoke(), ranges that are pleasant to use (0 .. 10).forEach { }, or when (floatVariable) { in 0.0f .. 1.0f -> ... }, pattern-ish matching with when (not quite full on functional language powerful, and I believe that Java is not only catching up to it but making their switch quite a bit better), a standard lib that is packed full of extremely useful and consistently named methods, extension functions, delegation (if you inherited a SDK that has a piss poor interface, you can simply make a SDKWrapper(val internalSdk: SDK): SDK by internalSdk, which means that it will automatically implement it, and you can then have your wrapper do whatever around it (logging, better functions, DI, etc.))) Kotlin is truly a pleasant language, both when you don't know it (although it can look a bit symbol soup-y at times for juniors), and when you fully know it.
  - origin_path 4y ago
    Just browse through the Kotlin standard library. It's basically just a set of mappings to the Java standard library with a whole lot of extension functions to make it easier to use.
quantified 4y ago
In HN a while back, an Oracle dev pointed out that the evolution is slow for a reason. Which confirmed slow. New releases every 6 months, but not that much in the way of changes. This isn't criticism of the fact of it or going into why it is or whether it should be that way. It's just a statement of fact.
Alupis 4y ago
> New Java versions are cut every six months since 2017 and since then has added a significant amount of new features And yet, the overwhelming majority of the Java community are still using JRE8 with none of these new features. There are some that love this new pace of language development, but very few are actually using new features in production code.
- yardstick 4y ago
  The hesitancy in jumping beyond JRE8 is the large backwards compatibility road bumps in JDK9-11, and now again with 17/JavaEE->Jakarta. I wish Java would continue to add new features but be a lot more considerate of avoiding, completely, migration headaches. We are migrating Java 8 -> 17 now and it’s been a right royal pain. I’m glad we didn’t jump to 11 LTS, and instead make one big leap. It might be a very long time before we do another LTS upgrade if they keep making poor migration choices.
  - kaba0 4y ago
    The only relatively bumby migration was 8->9. After that it is a very smooth ride, and that bumpiness was the price for the accumulated tech debt/slow down from the end of the Sun era.
    - vips7L 4y ago
      8 -> 9 wasn’t that hard for me personally. For our applications it was just adding things to the build to make sure javax.xml was present. The real difficulty for us was upgrading the Play framework since the Scala community likes to make breaking changes with every release.
    - Alupis 4y ago
      Well, my understanding is (but I have yet to personally experience) the migration from 17 -> 18+ is rough because of all the javax.* packages being renamed jakarta.* Which likely means touching a pretty significant portion of your codebase for the upgrade, and then who knows what 3rd party libraries you depend on are expecting... So it may be as simple as Find/Replace for some folks, for others, it might be a deep dark rabbit hole. Not breaking things used to be Java's MO. Yes, that means a ton of legacy cruft built up over the years... but we used to be able to depend on Java to "Just Work". Perhaps some of this is necessary. After all, the C# folks seem to have no problem breaking everything to add new features... but I'd assert the Java community as a whole is much less tolerant of breaking changes and rapid deployment of features.

kaba0 4y ago

> iOS compatibility-ish I don’t know how well it works, but we have seen these kinds of projects, and they seldom work as is. Not sure how well Scala Native works, even though it predates Kotlin’s try. (Though scala.js is surprisingly good!) But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java? Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms. For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane). > Java is still very slow to evolve Is it a problem? The majority of developers don’t like running after the language, even though it may seem so based on online hype circles.

ohgodplsno 4y ago
>I don’t know how well it works, Well enough, provided you stay within the known bounds. Hell, some people at Touchlab even went as far as porting Jetpack Compose to work on iOS (which, uh, I would not recommend in its current state), and it technically works. I probably wouldn't recommend writing all of your app logic in Kotlin, but being able to share the data layer is amazing. >But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java? It depends on where you're looking. Most modern android development will most likely be done in Kotlin. Backend work, for things started relatively recently, Kotlin is not surprising. But mostly, Java does not make iOS compatibility a goal. Java tell you "get a JVM and run our shit" (or get GraalVM and have basically an embedded JVM). Kotlin has two sides, and Kotlin/Native does not depend on the JVM. >Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms. j2cl still brings in a light JVM to the Web. Kotlin does not. It provides interop to the JS APIs as well as its own tech, but it's not meant to take your Kotlin code and immediately run it on the web (which is an awful, awful idea). You're still meant to write your browser specific code, your android specific code, your x86 specific code, etc. In any language you want, even! Write it in Kotlin/JS, or let your typescript consume the Kotlin/JS bindings. However, you can have a common base that'll work everywhere. > For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane). Graal is an extremely cool project, but with different goals. Write once, run everywhere is a lofty goal, but it only works on very similar platforms (Windows/Linux/OSX). Kotlin has taken a Write once, specialize what is needed approach.

bitexploder 4y ago

Do languages really need new features every N months to stay relevant?

nordsieck 4y ago
> Do languages really need new features every N months to stay relevant? I think a fixed N month release schedule is much healthier than what Java did before, which was wait until everyone was on the bus in order to ship, which resulted in multi-year delays.
ohgodplsno 4y ago
Depends. Is stuff like context receivers (https://nomisrev.github.io/context-receivers/ https://nomisrev.github.io/context-receivers/) needed ? No, although it's a fun experiment. Are multiple receivers needed (https://youtrack.jetbrains.com/issue/KT-10468/Multiple-receivers-on-extension-functionsproperties https://youtrack.jetbrains.com/issue/KT-10468/Multiple-recei...) ? Not really, but when you are dealing with the JVM, nested class hell is a very common thing, and cleaning up your code is always pleasant. Implicit namespacing ? (https://youtrack.jetbrains.com/issue/KT-11968/Research-and-prototype-namespace-based-solution-for-statics-and-static-extensions https://youtrack.jetbrains.com/issue/KT-11968/Research-and-p...) Fun thing to get. The thing is, they're all optional. You're never going to use any of these features if you don't need them. Your code can stay as a nested list of calls. But put them all together, and you can have code that is super explicit about what it needs to do, without having to re-pass things that are already there.
AnimalMuppet 4y ago
Depends. Are the features making things better, or just more complicated? Even if it makes things better only for, say, 10% of users, but doesn't make it worse for the other 90%... the users will take that every N months for as long as the language authors can do it.
kaba0 4y ago
No, but fortunately Java doesn’t do that. They have long running projects, when one is nearing completion it will be put in preview in the upcoming release. No rush to make it into anything, it’s ready when it’s ready. (Which should be copied by the rest of the industry as well)

biztos 4y ago

I’m not a Kotlin user, but this struck me as ambitious: > having the entire Java ecosystem available and, in the same point: > Compilation for so many platforms, directly to native executables Does this mean you can compile pretty much any Java libraries to non-JVM executables?

MrPowerGamerBR 4y ago
No, if you are targeting a different platform you can't use JVM libraries. If your target is JavaScript, you can use JavaScript dependencies (sort of: they won't have any type bindings so you will need to code then yourself) but you can't use any JVM libraries on it.
slively 4y ago
No, if you use Kotlin native you do not get access to Java libs.
ohgodplsno 4y ago
As other said, yep, you do not get the Java ecosystem if your target is native executables (or JS). there are alternatives like kotlinx-datetime, kotlinx-serialization, the kotlin stdlib. However, if you know you're going to stay on a JVMable target, feel free to not use Kotlin/Multiplatform, but regular JVM Kotlin libraries

yCombLinks 4y ago

Slow to evolve and long-term backwards compatibility are selling points.