Just use Kotlin. I'm honestly not seeing any need nor benefit in writing Java anymore.

I‘d say its the other way around, Java is closing the gap, and I say that as a Kotlin fan. Nullability in the type system is the big remaining advantage.

Scope functions are still huge. Yes, deep let chains can certainly be considered an antipattern (sometimes I like the approach of writing them, then transforming to more imperative for readability, I think readability peaks at a mix of imperative with some shallow .let), but I miss them in any language that is not kotlin.

Variables should be the exception, not the norm. I have no patience for names that designate some fluid work in progress instead of a value.

> Scope functions are still huge

They can be useful, but I can never remember which one of let, run, with, apply, and also I currently need. Also, I've noticed that they motivate overly "clever" code, especially but not exclusively in junior programmers.

They absolutely do come with a goldilocks problem attached, best used in moderation, and require a bit of an aesthetic to develop. But what doesn't. What appears "clever" to the reader is actually dead simple train of thought coding at write time, with many types of bugs waiting to bite in an imperative implementation simply not possible.

That's why I like writing scope-heavy and then transforming to an aesthetic middle ground between scope expression and imperative. Name stuff when you have something meaningful to say, when there's something helpful to express in a name, not when the syntax mandates a locally unique ID.

> Scope functions are still huge.

I’d put any one of extension methods, value and data classes, immutable variables, structured concurrency, and top-level functions ahead of scope functions for reasons to switch to Kotlin. But hey, if you’re switching, we’re already friends :) .

Really, top level functions? I fail to see their impact, outside of getting rid of ceremony around trivial code examples.

You missed optional and named arguments in the list, those really change cost/benefit decisions in API design. (and, unfortunately, make argument names part of the public interface, this must be the most controversial part in all of kotlin)

I singled out scope functions because all those other things feel very much like the usual set of language differences, whereas scope functions feel completely orthogonal. They could be added to every single language that has excursions and imperative elements, and they would be about the same improvement everywhere.