I think you misunderstood me — the rare situation is the compiler complaining about valid code. In practice, I find null handling in Kotlin to be quite straight

I think you misunderstood me — the rare situation is the compiler complaining about valid code. In practice, I find null handling in Kotlin to be quite straightforward, and it simplifies both writing and reading code a fair bit. I also find that forcing me to opt in to allowing nulls and, therefore, complicating my code a bit (by correctly handling them in the implementation) forces me to clean up my designs a bit. Now, Jetbrains don't claim to solve data races in general, so it's fine to not solve all of them. But they _do_ claim to provide null safety in general (modulo java interop), so they _must_ provide null safety in the face of data races. I do agree that a language that solves data races in general is very, very valuable (and that's part of the reason why I've invested some time learning Rust), but solving nulls better than the half-arsed solution present in java Optional is, IMO, still quite valuable. Finally, what do you mean by "a false sense of security as a result of the !! operator"? The !! operator is effectively "I know for a fact this isn't null, stop bothering me", and, when you read it, it should raise alarm bells, rather than make you feel safe. I also object to the notion that a language that is a bit safer is bad because it lulls you into a false sense of security. That's like saying that GCs are bad because they lull you into a false sense of security from memory leaks.