3 ms·

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 platfor

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.

willsmith72 2y ago
wait a second, the improvement is 30 seconds to 10-15? how is that workable? that would drive me insane 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?
- __s 2y ago
  this may be the effect of what people are used to. Going from 30 to 15 is huge, even if it's awful compared to a couple seconds / hot reloading. I've worked on projects where the development loop required deploying to a test environment. You get used to programming without the feedback loop (not to say that this feedback loop shouldn't be sought after, only that one adapts to their circumstances)
  - mdaniel 2y ago
    I also hypothesized that working in an actual statically and strongly typed language leads to less "save, reload, pray" loops than a typical front-end developer may have gotten used to
- jillesvangurp 2y ago
  It's very usable. What you loose in performance, you gain in confidence provided by a statically compiled language. So, you can simply go longer in between reloads without risking too much fall out. If it compiles, it will probably run without a lot of weirdness. So there's less need to feel insecure whether things will still run. 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.

willsmith72 2y ago

wait a second, the improvement is 30 seconds to 10-15? how is that workable? that would drive me insane 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?

__s 2y ago
this may be the effect of what people are used to. Going from 30 to 15 is huge, even if it's awful compared to a couple seconds / hot reloading. I've worked on projects where the development loop required deploying to a test environment. You get used to programming without the feedback loop (not to say that this feedback loop shouldn't be sought after, only that one adapts to their circumstances)
- mdaniel 2y ago
  I also hypothesized that working in an actual statically and strongly typed language leads to less "save, reload, pray" loops than a typical front-end developer may have gotten used to
jillesvangurp 2y ago
It's very usable. What you loose in performance, you gain in confidence provided by a statically compiled language. So, you can simply go longer in between reloads without risking too much fall out. If it compiles, it will probably run without a lot of weirdness. So there's less need to feel insecure whether things will still run. 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.