Interesting.
From an outside perspective, I had the impression Java devs would migrate to Kotlin.
From an outside perspective, I had the impression Java devs would migrate to Kotlin.
I had the impression the Java build system was rather convulted.
My "convulted build system" experiences all came from Maven and Gradle.
Thousands, or tens of thousands of lines of semi-proprietary/non-standard XML is what made up ANT build scripts... mostly or entirely hand written for each and every project. Even small hobby projects had build scripts in the thousands of lines... there was no such thing as dependency management, and nothing came "for free". Every single thing had to be hand written into the script because ANT didn't have any inkling what you might want to do... build targets layered upon each other until rationalizing about what happens when during the build becomes a full time job all in it's own.
Maven is amazing. With a few lines of XML you can successfully build nearly every project, manage all dependencies, etc. The trade-off? It's extremely opinionated in how your project is managed and how it's laid out. Worth while in most cases.
I guess, for me, everything that is XML is just convulted legacy stuff.
Integrating with Java's existing build systems (Gradle, Maven) was one of JetBrains initial design goals to avoid the separate ecosystem requirement that initially came with Scala. I admit building Kotlin has some quirks, notably around annotation processors - but overall it is very seamless.
I am happy Java is adding new stuff (records, switch expressions, sealed classes), but I worry it is increasing overall language complexity vs. the fresh start that Kotlin was able to take. Supporting the legacy patterns in the language adds to the complexity any given Java developer is supposed to know.
Overall I think the sane defaults and nudges towards the right patterns Kotlin pushes are a much bigger deal than just reducing boilerplate - though that is nice too.
Kotlin got lucky with Android, Google should have all the fun with their own version of .NET.
Isn't exactly this happening now with Rust?
https://www.opengroup.org/openbrand/register/
Note that ISO C is part of POSIX certification.
Which is also a reason why it cannot get rid of the flaws it inherited from such relationship.
But in general it's just the same Java, e.g. you would search for "how to do that in Java", not "in Kotlin".
While Kotlin closures, receiver arguments, "it", extension functions, nullability operator, var/val, "when" pattern matching, sealed classes and smartcasts are mostly implemented as syntactic sugar, combining all of the above enables some interesting programming patterns. Some examples are Compose for building reactive/functional UI and TornadoFX for declarative UI on top of JavaFX.
Coroutines and suspend functions provide structured concurrency and an async paradigm that interopts well with the "old" Java CompletableFuture apis and existing libraries.
Kotlin Flow is the answer for observability and rx-like reactive programming.
Kotlin multiplatform (while still in early development) allows sharing code between JVM, web and native targets (even iOS) with a decent-ish build system.
I'm very bullish on the future of Kotlin and have been using it for years as my goto language for backend apis, MPA's, Android and JVM desktop projects. I'm excited to expand that into some combined web/iOS/android/desktop projects in the very near future.