6 ms·

What's New in Kotlin 2.0.0

124 points by farmerbb 2y ago

wfouche 2y ago
[dead]
binkHN 2y ago
Perhaps the most important piece of this: > ...the new Kotlin K2 compiler is used by default and it is Stable for all target platforms: JVM, Native, Wasm, and JS. The new compiler brings major performance improvements, speeds up new language feature development, unifies all platforms that Kotlin supports, and provides a better architecture for multiplatform projects.
fifteen1506 2y ago
I noticed [JetBrains] appears to have an UI framework which works on all 3 desktop OS and 2 mobile OS. Does anyone have hands-on experience?
- mike_hearn 2y ago
  It's inspired by React, but way more purist about it. So there's no CSS or equivalent, it's all done using contexts, there's no HTML, it's all React-style function components the whole way down. There are some advantages to doing things that way, but I found there were also disadvantages. How much you like it will depend on how much you like ReactJS.
- westnordost 2y ago
  You probably mean Compose Multiplatform? That is a fork, or rather, extension to Jetpack Compose, Google's declarative UI framework for Android. It uses Skia for rendering but has an the identical API to Jetpack Compose, hence from the point of view of a framework user, there is nothing new about it (other than that it works on Android, iOS, desktop OSs and web).
- jillesvangurp 2y ago
  Not hands on but I've been paying attention. IMHO several things world mentioning: - Compose desktop is for now dependent on the JVM. That is despite Kotlin now having a stable native compiler. Reason for this is that the library eco system is still lagging. That being said, you can build some nice things with it pretty quickly. - IOS support is not stable yet. It kind of works but you'd be an early adopter. - On web, there are two compose variants. Compose HTML is a bit of side show but uses a traditional DOM based approach. Compose web exists in wasm and js variants and renders its own components in a canvas either way. Compose web mainly makes sense for people wishing to target the web with their mobile Android/IOS code base. - Google just announced a recommended status for KMP on mobile at Google IO. So, this is significant in light of the recent layoff rounds affecting e.g. the Flutter and Dart teams. If you feel adventurous it's worth checking out now but you probably have to wait something like a year plus for this to stabilize on IOS. I'm personally curious to see how the whole wasm/web part evolves. The wasm compiler is currently alpha. My prediction is that compose multi-platform will stabilize over 2025 and will start going mainstream the year after. At that point it could become a serious alternative to flutter and react-native.
  - Starlevel004 2y ago
    > That is despite Kotlin now having a stable native compiler. K/N for desktop platforms exists basically in name only. The runtime is too slow, the ecosystem simply doesn't exist, and you have to go through the C interop layer (which was marked entirely unstable in a point release, breaking everything!!!!) to do things such as I/O which lacks any sort of resource management (making it trivial to e.g. leak sockets everywhere).
    - jillesvangurp 2y ago
      This could get better over time. Most of the native community seems focused on mobile. But if this is ever addressed, Kotlin could emerge as an alternative to things like Go and other statically compiled languages. It's early days for native. There are similar challenges with wasm support; particularly the wasmWasi target.
  - 2y ago
smallerfish 2y ago
I'm a big fan of Kotlin, but the developer experience in the IDE has been pretty rocky recently, various of their secondary libraries are semi-abandoned, and their ecosystem documentation is a mixed bag at best. My ideal for the next 12 months would be for them to focus solely on quality. There's incredible potential, but they're going to shoot themselves in the foot if they don't get on top of this soon.
- westnordost 2y ago
  Are you thinking of certain secondary libraries in particular?
jillesvangurp 2y ago
I've been an early adopter of Kotlin 2.0. We use kotlin for our backend (vanilla spring boot setup) and our frontend via kotlin-js. We also have a multi platform library for out backend API client. This powers both our server integration tests and our frontend. If you are wondering why we did that, it's mostly accidental. I had a kotlin/android developer and no time to retrain him on react/javascript. So we picked a Kotlin-js web framework and discovered that it worked well enough for us. It's called Fritz2 and relatively obscure. But definitely worth looking at. This setup has worked fairly well but it was a rough ride of the typical early adopter bugs, compiler issues, etc. over the years. Consequently when Kotlin 2.0 came out of alpha and entered beta last year, we tried it out and immediately liked it for one big reason: massively improved compiler performance. Especially with kotlin-js the difference was big enough that we were reluctant to revert back to 1.9. We are talking from edit -> compile -> webpack (by far the slowest thing now) round trips going from > 30 seconds to < 10-15 seconds. About half of that is webpack. I still wouldn't call it fast but it's definitely better. The early betas we had some code that didn't compile and we found some workarounds and on a few occasions engaged with the developers via the Kotlin slack on specific bugs. They are awesome and very responsive. By beta 2, we had everything working that we cared about. We didn't look back after that. I wouldn't recommend being an early adopter for bigger companies; but for us it was fine. Worst case would have been having to roll back to something that worked and then waiting for a fix. Highlights of this release are pretty simple: - no new language changes relative to 1.9. This is on purpose because the whole point of this release is the compiler. So, this should be an easy one to update to. Everything should just work. If it doesn't file a bug or fix your code because it probably does soms sub-optimal things. - New compiler backend and frontend that have come together over the last few several major releases. This clears the path for a lot of stuff. Including better IDE integration, language changes, and less headaches supporting different compiler targets. - wasm support is coming together (in alpha release currently). The main limitation is not the compiler but the lack of multi platform libraries that support it. This is slowly being addressed. I'm currently waiting for ktor-client to get support. Wasm has two targets: wasmWasi and wasmJs. wasmWasi is problematic with library support right now but should catch up in the next months. - Some improvements in the kts gradle dsl for the multi-platform plugin. Nice but not world shocking.
- 2y ago
newZWhoDis 2y ago
Does the compiler catch calls to throwing functions from non-throwing functions yet? That’s been a huge problem for us: Some lib/func 16 layers deep throws an exception and it’s wrapped in a non-throwing function so the higher-level caller has no idea the call can generate an exception and runtime crash the whole app.
- dtech 2y ago
  No, and it won't. Checked exceptions were explicitly removed compared to Java, and most people view them as a mistake (including the Java 8+ ecosystem e.g. streams). Try is a bit better and Kotlin has a bit of that with Result + runCatching. You can find a pretty good overview of the Kotlin error handling phylosphy here [1] [1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#error-handling-style-and-exceptions https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
  - jmaker 2y ago
    Also, Arrow.kt is worth mentioning for functional error handling.
MobileVet 2y ago
Kotlin is great, but we are having a hard time finding solid devs due to the smaller ecosystem for it. If anyone is looking or just wants to find a place that truly cares about its customers and team, please give me a shot out. We pay very competitively, share company profits and give everyone 3 weeks off over winter. You wont have a 1/10000 chance of your options going to the moon, but you will love the team, the mission and you will never get called after 5. https://www.pocketprep.com/jobs/ https://www.pocketprep.com/jobs/
- tempaccount420 2y ago
  > Kotlin is great, but we are having a hard time finding solid devs due to the smaller ecosystem for it. Well, maybe you need to train them?
  - BandButcher 2y ago
    I would advocate for this. If your codebase is low in complexity then I think it would be wise to invest engineering time towards kotlin training. I've taken several courses on pluralsight and they get you up to speed quickly but informatively. Also if you place kotlin in high regards or believe it saves you time/money as opposed to java (as i do too) then why not train java devs on kotlin and introduce them to a low complexity app before high complexity sets in (potentially)
- jmaker 2y ago
  You could try extending your candidate pool if you haven’t yet. Java devs are the fastest to onboard for Kotlin, also Scala, and vice versa. The stdlib APIs and the third-party libraries are the same, plus you get the Kotlin libraries. Lots of modern Java projects transition piecewise to Kotlin, so often hiring for Java turns out to be for Kotlin, in part or in whole.
  - MobileVet 2y ago
    That is a good call. Having platform knowledge is definitely a plus, but core language skills are probably more important considering the minimal complexity of our system.
aixpert 2y ago
funny that they mentioned Gradle as the first feature change when the only thing we requested was the compiler to run without this gradle mess
- simon_void 2y ago
  you can use Kotlin in a Maven project as well (configuration here: https://void2unit.onrender.com/post/multimodule-maven-java-kotlin-config/ https://void2unit.onrender.com/post/multimodule-maven-java-k...) or maybe your request is what triggered Jetbrains to develop Amper (https://blog.jetbrains.com/amper/ https://blog.jetbrains.com/amper/)
  - aixpert 2y ago
    I'd love to use kotlin standalone, as other normal programming languages, without any configuration scripts or build tools
    - penguin_booze 2y ago
      A while ago, I tried compiling a simple Kotlin hello world on the command line (my preferred "IDE"). I vividly recall it taking around 7 seconds to even compile, every time. It could be that my rickety laptop was to blame, but not probably wholly. AFAICT, the only viable avenue of Kotlin developemnt is by using an IDE (or maybe launch a Gradle deamon--but that'll be another rant).
      - bsdooby 2y ago
        And that is my major criterion for every modern programming language: How easy is it to use on the CLI (also my preferred IDE)? IMHO all fail there
        ta988 2y ago
        If you accept to use gradle, then Kotlin works great without an IDE.

124 points by farmerbb 2y ago

[dead]

Perhaps the most important piece of this: > ...the new Kotlin K2 compiler is used by default and it is Stable for all target platforms: JVM, Native, Wasm, and JS. The new compiler brings major performance improvements, speeds up new language feature development, unifies all platforms that Kotlin supports, and provides a better architecture for multiplatform projects.

fifteen1506 2y ago

I noticed [JetBrains] appears to have an UI framework which works on all 3 desktop OS and 2 mobile OS. Does anyone have hands-on experience?

mike_hearn 2y ago
It's inspired by React, but way more purist about it. So there's no CSS or equivalent, it's all done using contexts, there's no HTML, it's all React-style function components the whole way down. There are some advantages to doing things that way, but I found there were also disadvantages. How much you like it will depend on how much you like ReactJS.
westnordost 2y ago
You probably mean Compose Multiplatform? That is a fork, or rather, extension to Jetpack Compose, Google's declarative UI framework for Android. It uses Skia for rendering but has an the identical API to Jetpack Compose, hence from the point of view of a framework user, there is nothing new about it (other than that it works on Android, iOS, desktop OSs and web).
jillesvangurp 2y ago
Not hands on but I've been paying attention. IMHO several things world mentioning: - Compose desktop is for now dependent on the JVM. That is despite Kotlin now having a stable native compiler. Reason for this is that the library eco system is still lagging. That being said, you can build some nice things with it pretty quickly. - IOS support is not stable yet. It kind of works but you'd be an early adopter. - On web, there are two compose variants. Compose HTML is a bit of side show but uses a traditional DOM based approach. Compose web exists in wasm and js variants and renders its own components in a canvas either way. Compose web mainly makes sense for people wishing to target the web with their mobile Android/IOS code base. - Google just announced a recommended status for KMP on mobile at Google IO. So, this is significant in light of the recent layoff rounds affecting e.g. the Flutter and Dart teams. If you feel adventurous it's worth checking out now but you probably have to wait something like a year plus for this to stabilize on IOS. I'm personally curious to see how the whole wasm/web part evolves. The wasm compiler is currently alpha. My prediction is that compose multi-platform will stabilize over 2025 and will start going mainstream the year after. At that point it could become a serious alternative to flutter and react-native.
- Starlevel004 2y ago
  > That is despite Kotlin now having a stable native compiler. K/N for desktop platforms exists basically in name only. The runtime is too slow, the ecosystem simply doesn't exist, and you have to go through the C interop layer (which was marked entirely unstable in a point release, breaking everything!!!!) to do things such as I/O which lacks any sort of resource management (making it trivial to e.g. leak sockets everywhere).
  - jillesvangurp 2y ago
    This could get better over time. Most of the native community seems focused on mobile. But if this is ever addressed, Kotlin could emerge as an alternative to things like Go and other statically compiled languages. It's early days for native. There are similar challenges with wasm support; particularly the wasmWasi target.
- 2y ago

smallerfish 2y ago

I'm a big fan of Kotlin, but the developer experience in the IDE has been pretty rocky recently, various of their secondary libraries are semi-abandoned, and their ecosystem documentation is a mixed bag at best. My ideal for the next 12 months would be for them to focus solely on quality. There's incredible potential, but they're going to shoot themselves in the foot if they don't get on top of this soon.

westnordost 2y ago
Are you thinking of certain secondary libraries in particular?

jillesvangurp 2y ago

I've been an early adopter of Kotlin 2.0. We use kotlin for our backend (vanilla spring boot setup) and our frontend via kotlin-js. We also have a multi platform library for out backend API client. This powers both our server integration tests and our frontend. If you are wondering why we did that, it's mostly accidental. I had a kotlin/android developer and no time to retrain him on react/javascript. So we picked a Kotlin-js web framework and discovered that it worked well enough for us. It's called Fritz2 and relatively obscure. But definitely worth looking at. This setup has worked fairly well but it was a rough ride of the typical early adopter bugs, compiler issues, etc. over the years. Consequently when Kotlin 2.0 came out of alpha and entered beta last year, we tried it out and immediately liked it for one big reason: massively improved compiler performance. Especially with kotlin-js the difference was big enough that we were reluctant to revert back to 1.9. We are talking from edit -> compile -> webpack (by far the slowest thing now) round trips going from > 30 seconds to < 10-15 seconds. About half of that is webpack. I still wouldn't call it fast but it's definitely better. The early betas we had some code that didn't compile and we found some workarounds and on a few occasions engaged with the developers via the Kotlin slack on specific bugs. They are awesome and very responsive. By beta 2, we had everything working that we cared about. We didn't look back after that. I wouldn't recommend being an early adopter for bigger companies; but for us it was fine. Worst case would have been having to roll back to something that worked and then waiting for a fix. Highlights of this release are pretty simple: - no new language changes relative to 1.9. This is on purpose because the whole point of this release is the compiler. So, this should be an easy one to update to. Everything should just work. If it doesn't file a bug or fix your code because it probably does soms sub-optimal things. - New compiler backend and frontend that have come together over the last few several major releases. This clears the path for a lot of stuff. Including better IDE integration, language changes, and less headaches supporting different compiler targets. - wasm support is coming together (in alpha release currently). The main limitation is not the compiler but the lack of multi platform libraries that support it. This is slowly being addressed. I'm currently waiting for ktor-client to get support. Wasm has two targets: wasmWasi and wasmJs. wasmWasi is problematic with library support right now but should catch up in the next months. - Some improvements in the kts gradle dsl for the multi-platform plugin. Nice but not world shocking.

2y ago

newZWhoDis 2y ago

Does the compiler catch calls to throwing functions from non-throwing functions yet? That’s been a huge problem for us: Some lib/func 16 layers deep throws an exception and it’s wrapped in a non-throwing function so the higher-level caller has no idea the call can generate an exception and runtime crash the whole app.

dtech 2y ago
No, and it won't. Checked exceptions were explicitly removed compared to Java, and most people view them as a mistake (including the Java 8+ ecosystem e.g. streams). Try is a bit better and Kotlin has a bit of that with Result + runCatching. You can find a pretty good overview of the Kotlin error handling phylosphy here [1] [1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#error-handling-style-and-exceptions https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
- jmaker 2y ago
  Also, Arrow.kt is worth mentioning for functional error handling.

MobileVet 2y ago

Kotlin is great, but we are having a hard time finding solid devs due to the smaller ecosystem for it. If anyone is looking or just wants to find a place that truly cares about its customers and team, please give me a shot out. We pay very competitively, share company profits and give everyone 3 weeks off over winter. You wont have a 1/10000 chance of your options going to the moon, but you will love the team, the mission and you will never get called after 5. https://www.pocketprep.com/jobs/ https://www.pocketprep.com/jobs/

tempaccount420 2y ago
> Kotlin is great, but we are having a hard time finding solid devs due to the smaller ecosystem for it. Well, maybe you need to train them?
- BandButcher 2y ago
  I would advocate for this. If your codebase is low in complexity then I think it would be wise to invest engineering time towards kotlin training. I've taken several courses on pluralsight and they get you up to speed quickly but informatively. Also if you place kotlin in high regards or believe it saves you time/money as opposed to java (as i do too) then why not train java devs on kotlin and introduce them to a low complexity app before high complexity sets in (potentially)
jmaker 2y ago
You could try extending your candidate pool if you haven’t yet. Java devs are the fastest to onboard for Kotlin, also Scala, and vice versa. The stdlib APIs and the third-party libraries are the same, plus you get the Kotlin libraries. Lots of modern Java projects transition piecewise to Kotlin, so often hiring for Java turns out to be for Kotlin, in part or in whole.
- MobileVet 2y ago
  That is a good call. Having platform knowledge is definitely a plus, but core language skills are probably more important considering the minimal complexity of our system.

aixpert 2y ago

funny that they mentioned Gradle as the first feature change when the only thing we requested was the compiler to run without this gradle mess

simon_void 2y ago
you can use Kotlin in a Maven project as well (configuration here: https://void2unit.onrender.com/post/multimodule-maven-java-kotlin-config/ https://void2unit.onrender.com/post/multimodule-maven-java-k...) or maybe your request is what triggered Jetbrains to develop Amper (https://blog.jetbrains.com/amper/ https://blog.jetbrains.com/amper/)
- aixpert 2y ago
  I'd love to use kotlin standalone, as other normal programming languages, without any configuration scripts or build tools
  - penguin_booze 2y ago
    A while ago, I tried compiling a simple Kotlin hello world on the command line (my preferred "IDE"). I vividly recall it taking around 7 seconds to even compile, every time. It could be that my rickety laptop was to blame, but not probably wholly. AFAICT, the only viable avenue of Kotlin developemnt is by using an IDE (or maybe launch a Gradle deamon--but that'll be another rant).
    - bsdooby 2y ago
      And that is my major criterion for every modern programming language: How easy is it to use on the CLI (also my preferred IDE)? IMHO all fail there
      - ta988 2y ago
        If you accept to use gradle, then Kotlin works great without an IDE.