Null Safety: Kotlin vs. Java | Hacker News Reader

Null Safety: Kotlin vs. Java

blog.frankel.ch

29 pointssaikatsg21 comments

> Java will never be able to compete with Kotlin in this regard, as Java language architects value backward compatibility over code safety.

Never is a strong statement. The java team spends a good amount of time thinking on how they could bring Nullability into the type system. It’s certainly possible we could get it as apart of Project Valhalla - https://mail.openjdk.org/pipermail/valhalla-spec-experts/202...

Aside from future language changes that could bring direct null safety, there are practical tools like NullAway that essentially give us everything Kotlin has.

I think null types is a worse solution than annotations...the only thing we need is a true standard.

I’m still not sold on compiler enforced nullable types. They feel like colored functions/checked exceptions all over again. Adding null to the type system is just going to result in deep call chains where you need to modify every signature or developers will end up just throwing random unchecked exceptions to escape the type system and make the compiler happy which in my eyes is no different than an NPE.

I don't know why this reiteration of the widely known (and ancient) things worths any attention.

Especially considering that the author doesn't explicitly mention Option monad, for-comprehension and all the right generalizations solving the problem properly.

Until Kotlin creates its own ecosystem, based on Kotlin/Native or something, it isn't competing with Java at all, regardless of the features, it isn't the target language that JVM designers care about, or use in the standard library.

Which is so mature that JetBrains is using Rust instead for their Fleet backend.

Only on Android has Kotlin an advantage, thanks to Google pushing it as a replacement.

> Which is so mature that JetBrains is using Rust instead for their Fleet backend.

That doesn't make a lot of sense.

It sure does, Kotlin/Native isn't up for the task.

Doesn't mean it isn't up to the task for plenty of other things. This is like the definition of FUD.

And I have worked in Kotlin and hate it - and I'm saying this!

Curious to know , what do you hate in that language ? As a non-java dev, but user of more modern languages, it looks like a no brainer : more type safety, and compatibility with jvm ecosystem..

Just cause they made the language expecting them to use it for everything seems a bit harsh.

Explicit nullability has emerged as the clear victor.

But Kotlin has other stability issues. Owing to that, Android Studio is actually the least stable IDE I've ever used, with frequent dead locks. With both threads and coroutines and different forms of synchronization that may or may not work with both it's quite difficult to use correctly I suppose.

Eh, I think this is a bit of a strawman. Yes, you can write obtuse Java code where you need to null check (or optional-unbox) everything. You can also write java code where every function has an integer return value that you need to check like in C, or any other weird and error-prone paradigm.

You can also just avoid returning nulls and not have this problem at all. I think unless you're dealing with code that was written close to 20 years ago, or was written by someone living under a rock for as long, nulls will rarely be a problem. Putting tons of effort into building strong compiler guarantees that prevents a problem that at best is hypothetical seems like more effort than it is worth.

Unfortunately not. Nulls are alive and well. Our teammates are putting them into our codebases as we speak.

You should consider talking to them about adopting 21st century coding conventions.

It's like an agile backlog. The stuff I want to correct grows much faster than what I have the social capital for.

E.g. "being able to run your service locally and meaningfully" is something that's more important to me than no-nulls.

Is it null really meaningful?

With built in null safety, null becomes a useful result to pass around.

I think it's still probably a bad pattern to sometimes return a useful value through the same channel, whether through nulls or something else.

Nothing is a useful and meaningful result in a lot of cases. This is essentially a degenerate case of a discriminated union.

There are other choices that can be used to the same effect, such as exceptions or sealed classes. Of course, you can still use Optional<T>. But with null safety, a nullable return type is often most elegant and it's idiomatic in Kotlin.

A simple example would be going through a rest response. If a value is present the text should display, if it isn't return null. Passing back a blank string would be the bad pattern.

> Passing back a blank string would be the bad pattern.

That would actually be idiomatic Java behavior.

But with REST, I think you should return different status codes and different types entirely if you're returning an error. Not try to communicate through the presence of absence of fields. You should definitely not return half-complete representations when something half-worked. Either it's complete and guaranteed to be fully populated, or it's not returned at all.

e.g.

  HTTP 200: { "message": "hi mom!" }

  HTTP 404: { "error": "you came to the wrong neighborhood!" }

Reply on news.ycombinator.com