I can echo the Author's sentiment. I've been working with Java and lately Kotlin for the past 25 years. The last five of which almost exclusively with Kotlin.

I can echo the Author's sentiment. I've been working with Java and lately Kotlin for the past 25 years. The last five of which almost exclusively with Kotlin. Switching back to Java feels increasingly awkward at this point. I can do it, but there are no use-cases where I would prefer Java over Kotlin. I certainly don't enjoy it. Sure, they've added features to the language and they help but it's just not even close to the language ergonomics that Kotlin has. The val vs. var thing is super relevant because this is actually something that is more cultural than language related. As the author points out, you could just litter your Java code with final and it would be similarly safe code. But the reality is that very few people do that. Java makes you do the wrong/less safe thing by default. Kotlin has this opposite culture where you feel slightly guilty/dirty every time you even make something a var. Having a difference between mutable and immutable lists and maps is likewise something that Kotlin inverts. In Java you could always make lists and maps immutable but they'd be immutable by default. With Kotlin it's the reverse: everything is immutable unless you make it mutable. It's this safe by default attitude that pervades Kotlin that just shows up in a lot of places. Nullability as part of the type system removes an entire category of bugs. The only time I still see NPEs, it usually involves some Java library that I'm using. Considering how easy it is to switch from Java to Kotlin, it's not surprising that you see essentially all the major Java frameworks come with excellent Kotlin support. I use Spring Boot with Kotlin. It's quite obvious to me that using spring without Kotlin is a bad move at this point. There's so much good stuff you miss out on that is added to Spring via extension functions. E.g. having co-routines sit on top of webflux, makes the whole business of using asynchronous IO with Spring a lot less painful. Without that, I'd probably still be doing synchronous IO.