It's funny actually: my java code had mostly made peace with null. A combination of tireless performance of that if-dance where necessary, generous use of static methods for certain routine tasks on nullables and most importantly, @NonNull and null object singletons creeping into more and more code.

Now in kotlin it feels like it's just "drown it in question marks". I certainly end up with lots of nonnull signatures and far more reliable null handling than in java, but the ease almost feels wrong.

I am using more and more kotlin these days as an Android app dev

it starts that way, but over time you don't need the question marks as much because you're dealing with more and more code where the variables are guaranteed to not be null.

Where my code is mostly interacting with itself I see question marks almost as rarely as I saw Optional during my scala adventures (still can't believe a decade went by!), but the android API provokes it's share of nullability and the kotlin approach to deal with it is just so "why didn't we have that back in the MIDlet days!"

Some coworkers seem to type questionmarks faster than that IntelliJ "convert to kotlin" button and I hate it, but much less than I'd expect.

There’s also Java Optionals for wrapping everything into a tidy package. Optional.ofNullable is very neat.

Question marks are basically more concise Optional chaining.

Thanks to reddit's bad design, you missed this response all about null: https://old.reddit.com/r/java/comments/ndwz92/can_i_get_some...

I really think Goetz/the Java language people are waiting to see if nullable types actually pay off in C#/Kotlin first, like with every feature, before considering it.

In other areas they're already trying. e.g.

  if (o instanceof SomeClass) {
    o.someClassMethod();
  }

Following this line of reasoning I could want to assign it to a local var:

  if (o instanceof SomeClass) {
    final var s = o;
    ...
  }

An analogous situation arises with null:

  if (o != null) {
    final var s = o;
    ...
  }

Making the type of `s` a non-null type of `o`s type.

The annoying thing with Java language development is that they just don't seem interested in rounding it out with consistency/completeness.

Java went the route of Optional<?> instead of nullable types. You still end up with some nullability issues working with old libraries (and even the std lib, like Map.get()) but by and large you can force a "never use null" policy on Java codebases and NPEs become very rare.

I fairly strongly prefer Optional over nullable types. Especially how it works seamlessly with streams.

It's actually kind of instructive to consider how Scala mostly solved the NPE issue by simply having Option available and discouraging use of null.

There are still issues at the API boundaries with Java or JS code, but that's about it. Outside of that, NPEs are usually in more niche places to do with initialization order and that sort of stuff.

Of course if you're inventing a totally new language you probably want to just avoid the possibility of null outright.

The "never use null" policy doesn't work across your third party dependencies, unless those dependencies coincidentally use the same policy as you.