Hacker News Reader

Unfortunately immediately undermined by the decision to not address nullability out of the gate. It's fantastic that null pointer exceptions are well-defined on the JVM - but they still tend to bring your program to a screaming halt.

View on HN

I believe that the parent is talking about how Java, and in turn the JVM, defines its memory model, which describes formally how memory reads and writes occur in the presence of multiple threads of execution. For example, data races are well-defined in Java: Either you read the old or the new value, you'll never read a mix of two values.

Having a well-defined memory model is important when running on infra with very different models, such as x86 and aarch64.

Is it a big difference if you have ValueNotPresentException from nullable unwrap instead of NullPointerException?

Oh, wait, it exists https://docs.oracle.com/javase/8/docs/api/java/util/Optional...

The big difference is that Optional has ergonomic features like .map(), .ifPresent(), .orElse(), that reduce the verbosity of repeated if blocks checking if values are present or not.

The problem is basically every type is implicitly Optional and basically every operation implicitly unwraps, instead of only the cases where nullability is actually desired.

Reply on news.ycombinator.com