Well, ideally you start new projects writing 100% Kotlin while only adding Kotlin code to older codebases you can’t get rid of. Personally, I don’t like mixing languages anyway and I would stay with Java in Java projects. One reason is the bloat argument you pointed out quite correctly.

True… but Kotlin makes Lombok quite unnecessary by having its concepts built in. It’s also worth to point out that null safety is opt-in in Java and opt-out in Kotlin.

Yes, there are things about Kotlin I don’t love either. But I still like how it was clearly developed having developer quality-of-life in mind.

Kotlin isn’t perfect and it gives the devs quite a lot of freedom. I would argue that if your Kotlin code is messy, that’s on you - but it will still be significantly less prone to failures like NPEs. Unless you opt out of null safety by using the dreaded ?-Operator.

NPEs are the reason why my team moved to Kotlin. Well, that and all the other myriad advantages Kotlin brings to the table.

Even then, a BMW would tailgate and flash its headlights at you on a German autobahn.

The sticker should also say something like “But don’t worry, we’re going to be evaporated in a huge explosion anyway, due to the gigantic release of energy when you crash into my car in a few nanoseconds.”

Clever, I like it. I wonder how many people read it and have no clue what it means.

Ooh, shots fired.

I hate warriors, too narrow-minded. I’ll tell you what I do like though: a killer, a dyed-in-the-wool killer. Cold blooded, clean, methodical and thorough. Now a real killer, when he picked up the ZF-1, would’ve immediately asked about the little red button on the bottom of the gun.