> Structured Concurrency I think the two languages mean slightly different things here. In any case, Java's model is so much more simpler that I don't think th

> Structured Concurrency I think the two languages mean slightly different things here. In any case, Java's model is so much more simpler that I don't think they are honestly comparable. In kotlin's case you have to be very on top of your game to have a chance of correctly using it - there is concurrency, parallelism, exception handling all combined into a single abstraction in a non-native way - so your stack traces will be useless/swallowed etc on incorrect usage. Of course the usual caveat applies, just use java's abstraction if you need that. > Standalone function Don't really see the benefit, if anything it creates place for style disagreements. A SomethingUtil class was just fine (and findable). > Properties Difficult topic with both cons and pros. > Data classes Exactly because they are "more powerful" they are strictly worse. A design element is just as much about what it is as it isn't. Copy is good though. > Delegation Used a couple of times, but it's not the full blown thing (see manifold) > Extension method I will be honest, I really dislike these. They can occasionally help a bit with some DSL, but for the most part they just make code very hard to read. I much prefer a normal static method instead. > Context parameters One of the few useful syntactic sugar. > Operator overloading Argued to death already :) > Inline function Feels more like a hack to support some of these extra features than something you would want to use yourself > Block syntax For the rare DSL usecase it's useful. Everywhere else I really dislike it and the accompanying coding style. These .also and similar implicit receiver thingies are just straight up evil. All in all, there are a few things that are very elegant in kotlin, but I feel they went the c++ c# way of over abstracting just to have a long feature list.