> ...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.
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.
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.
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.
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.
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)
We don't give equity. The company is bootstrapped and the founders ran it completely until cash flow positive. It is now a fantastic mission driven small business, not a startup, focused on post graduate certification exam prep.
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.
> 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).
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.
I also think that in the longer term Google's embrace of KMP does not bode well for Dart and Flutter, especially in light of recent cost-cutting measures.
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).
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.
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).
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.
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.
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)
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
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.
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]
> ...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.