> NPEs in Java have become rarer and rarer recently with the introduction of records
While this is true, I think it goes back farther than that. NPEs became rarer since java.util.Optional and people taking the time to use JSR 305 nullability annotations. I do this on regular basis and haven’t seen NPEs in my work for ages now.
Because I’ve taken on projects with large Java codebases often written by people with poor code-design skills, I can say the single most frequent NPE offender I’ve seen was method bodies wrapped in: try { } catch {} return null.
Modern language features like Kotlin’s non-null fields are nice, but I hold self-discipline just as important.
Oh yeah, I agree with you on all those points. I guess what I'm trying to say is I feel like modern Java pushes you towards writing null-safer code than something like Go. I don't see the same push in modern Go.
This blog post is a great reference for "when to actually handle the nil case in Go" (and I think these ideas can even be applied to other languages), but there's nothing pushing anyone towards doing it the correct way in Go other than a documented team coding standard or an AGENTS.md/SKILL.md file.
In older Java applications there's also nothing pushing developers towards "correct null handling." A legacy Java application has a bunch of POJOs with getters and setters where all the fields start as null. That's why I think using records+JSpecify+NullAway is incredibly powerful in a Java project. NullAway really forces you to correctly and fully null annotate your code.
Self-discipline is great but static analysis tools actually enforce doing something "the right way." Things slip through code review, but a failing pipeline has to be fixed before the merge can happen.
Kotlins nice, mutability in the collections and nullable types are nice but they still lack some form of checked error handling. I really wish they would have taken checked errors exceptions further and made them usable.