Hacker News Reader

Comment by jeroenhd | Hacker News Reader

Until Java fixes its type system to add nullable types (and not in that ridiculous tri-state nullability method that one JEP proposes), Kotlin will be several steps ahead of Java.

I can speak from experience that Fable 5.1 still writes code that compiles and usually runs fine but throws null pointer exceptions in reasonable edge cases.

View on HN

That's valid. Kotlins nullable types do help tremendously in that regard with AI-generated code. If Java nailed a nullable type system that's actually a win for Kotlin as well since Kotlin has to support "platform types" where it can't tell if Java code is producing null or non-null types.

That's probably the largest gap in usability.

Waiting so long for type safety and hoping it won't be a weird implementation.

Kotlin's implementation is very good, hoping with all my heart java will copy it

The JEP is what I would call a weird implementation: https://openjdk.org/jeps/8303099

Types would be nullable (default), explicitly nullable (new), and explicitly non-nullable. Concretely, something is nullable, nullable, or non-nullable.

"Nullness is ignored when determining whether two methods have the same signature" is also rather annoying, this takes away the ability to provide fast overloads for non-null types for instance. Feels like a missed opportunity to me, though I'm sure there are reasons for that.

I love Kotlin and prefer to write it over Java nowadays but Kotlin has the same tristate nullability. It has nullable, non-nullable, and platform types when interacting with types from JS or Java.

Reply on news.ycombinator.com