> ...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.
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.
Well, maybe you need to train them?
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)
Does anyone have hands-on experience?
- 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.
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).
But for now Flutter seems like a much more mature stack, at least on desktop.
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).
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.
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.
maybe i'm spoilt, but modern frontend with hot reloading on save is just about instant.
even when i used kotlin (spring boot ~2.3), re-running a test with the intellij compiler took around 1 second.
is kotlin-js really usable with that performance?
Also, I should point out that this is on a largish three year old code base. Re-running tests without recompiling is similarly fast with kotlin-js. A Spring integration test with some code in main and test needing recompilation and the Spring Boot start up time will also set you back 15-20 seconds or so.
And as I pointed out webpack is at least half of the time you are waiting these days. IMHO, getting rid of that and replacing it with something faster could be worthwhile.
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.
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/...
